Side-effect free containers for E

[Mark S. Miller]

At 08:00 AM 8/10/00 , Tyler Close wrote:
>I think this cast of methods and associated operators should make
>answering question #1 from Markm's post a slam dunk for yes.

Seeing this comment at the end of your message took me aback.  It made me 
realize criteria I'd forgotten to state.  Sorry to change the rules on you 
mid game, but such is life.

Redesign Conservatism.  E has spent some time maturing.  Much less than many 
languages, but enough not to be sneezed at.  It has users and an installed 
base of working production software.  Ok, two programs, but one (EDesk) is 
substantial.  It has a community of interest (you guys), the people who 
should be our early adopters, mostly *not* investing their time in actually 
using the language, perhaps because of fear that it "isn't stable yet".  
Those familiar with my history may even have an exaggerated degree of this 
fear.  The current discussion may have already irreparably damaged any 
growing confidence you guys may have in E's upcoming stability.

This isn't a *definitive* argument for or against anything.  Being a 
Pan-Critical Rationalist http://www.maxmore.com/pcr.htm , I'm always willing 
to entertain new arguments. But this many radical changes at this point 
cannot be a slam dunk, even if the arguments for them on all other 
grounds are perfect.

That said, to my mind you've raised at least one compelling issue that's 
sufficient to cause a non-upward compatible change, and a wrenching one if 
needed.  When I made mutable collections as easy to use as immutable ones, 
and when I had them share most of their protocol (EList, EMap), then, as 
you point out, I did indeed create a security minefield.  A program which 
accidentally gave out a mutable collection instead of a snapshot of same 
would still continue to work under most benign conditions, but would have a 
hidden vulnerability due to an unintentional violation of the principle of 
least authority.  The E language as currently designed makes it hard for the 
programmer to catch such problems statically, and it's almost impossible to 
catch such problems dynamically by testing.

The same kinds of problems in our treatment of return values also caused us to 
make a wrenching non-upwards compatible change.  That change was smaller, 
but it was still surprisingly painful.


I'd also like to re-iterate the Familiarity criterion (to the C syntactic 
tradition).  Even on this ground alone, the previous email cannot be 
considered a slam dunk.  "Adequate functionality" and "syntactic 
convenience" are only two criteria among many that we need to balance.


         Cheers,
         --MarkM