Side-effect free containers for E

[Mark S. Miller]

Just to start things off, every C-syntactic tradition programmer pervasively 
uses the following assignment construct to mutate a single valued mapping:

     container[key] := newValue

In E (ignoring the issue that this must evaluate to the value of "newValue") 
this currently expands to

     container put(key, newValue)

Were normal-use containers only immutable, this is untenable.  The 
corresponding side-effect-free expression using the current E container 
class library is:

     container := container with(key, newValue)

This leaves the original container object alone, but derives a new one from 
it that's just like the original, except that the new one maps "key" to 
"newValue".  In order to provide similar syntactic support for this 
corresponding construct, we must *not* retarget the old syntax, as that would 
confuse everyone.  However, we can have our familiarity cake and eat it too 
by having the syntax

     container [key]= newValue

expand to 

     container := container with(key, newValue)

This leverages another aspect of the C syntactic tradition: "<op>=".  In all 
languages of this syntax, ignoring side effects and the value of the 
expression as a whole,

     i += 2

is equivalent to

     i := i + 2

If i originally held a number, it is universally understood that this number 
isn't mutated.  Rather, a new number is derived from the old, and the 
variable i is mutated to hold the derived number instead of the original.

Even if we keep mutable collections (reject suggestion #1), perhaps we 
should still provide the above sugar, in order to better encourage 
side-effect-free programming styles.  OTOH, I'm scared of having both 

     container[key]= newValue

and

     container[key]:= newValue
     
be legal in the same language with very different meanings.


         Cheers,
         --MarkM