[E-Lang] Operator expansion names, Part 1: Intro
Mark S. Miller
Fri, 06 Apr 2001 17:17:14 -0700
I don't know yet whether my next immediate focus will be CapTP (as
originally expected) or Hydro on the way to persistence. While I'm waiting
to gather the data to prioritize this, I thought I'd try to make some
progress of a major coordination issue needed for Hydro: the renamings of
the operator expansion names.
As already agreed on the list, these names will be taken from Python when
reasonable, but with a change in mangling convention. Where Python says
"__add__", E will instead say "op__add". I will take these by groups,
according to the arrangement rooted sat
http://www.python.org/doc/current/ref/specialnames.html . If this is not
the best reference material to use for this purpose, lemme know quickly.
For each operator, I will also try to state an informal sense of what I
think it should mean for a set of core datatypes, but these proposed
meanings will almost certainly take longer to settle than the operator to
name mappings, so let's see how separate we can keep these discussions.
(They can't be kept totally separate, since the right choice of name should
depends on the meaning.)
The controversy about the add operator led to a desire for a regression test
or a formal definition of what each operators means independent of datatype,
such that each datatype specific meaning could be tested for correctness wrt
the more general spec. I doubt such a thing is possible at this point.
It's not yet a matter of formal correctness or conformance, but one of
designed coherence and consistency. The latter are necessarily partially
For example, we might say the "normal" math notion of "+" is something like:
For each data type T to which + applies (after coercions), + should
be closed over T, such that for any t1 and t2 in T, t1 + t2 should also be
in T. For any such type T, there must also be a zero element of that
type t0, such that t1 + t0 -> t1 and t0 + t1 -> t1. + must also be
This is violated by both
[1, 2] + [3, 4] -> [1, 2, [3, 4]]
'a' + 3 -> 'd'
However, the first violation just bothers me in ways the second one doesn't.
The point is not to revisit this controversy, but to point out that, prior
to seeing these two violations, I would not have been able to think to state
correctness criteria that would have prohibited the first while allowing the
second. I think it must be this way.
Instead, once we have a set of agreed definitions of an operator for a set
of types, we can abstract from these what our criteria was (or could have
been). This retroactive rationalization is still not a spec, but is more
like a spec, making it that much harder to justify further broadening of
this retroactive sense of the meaning of the operator. It's more like
judgement by precedent than by legislation.
On to the operators...