[E-Lang] Operator expansion names, Part 1: Intro

[Mark S. Miller]

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 
artistic judgements.

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 
    associative.

This is violated by both 

    [1, 2] + [3, 4] -> [1, 2, [3, 4]]

and

    '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...

        Cheers,
        --MarkM