Side-effect free containers for E

[Mark S. Miller]

I see four somewhat separable issues in Tyler's proposal:

1) Should we remove mutable containers from the normal user container 
library?  (Whether they should continue to exist for specialized purposes 
would be a fifth issue, but I don't believe anyone is proposing that they be 
banished altogether.)

2) If we accept #1, what should the specifics of our side-effect-free 
container library be?  In particular, what current library should they 
derive from?  The two on the table are Hydro and the side-effect-free subset 
of the current E collections library.

3) What kind of syntactic support should E provide for these containers?
For example, what operator (eg, "+") should map to what 
container-manipulation meaning (eg, "concatenation of sequences").

4) Should immutable container use be made adequately efficient that normal 
programmer won't feel pressured to use mutable containers.

Let's dispense with #4 immediately.  Yes.  It was always my intention to 
provide such an implementation for the immutable container operations.  In 
particular, I expect to eventually implement sequences as Ropes (very 
similar to the Xanadu Model-T enfilade), and to implement hash-tables using 
Ken Kahn's backward-delta technique.  Perhaps Hydro already provides the 
needed efficiency.  If so, great.  But I don't think this issue effects any 
of the others.


Unfortunately, the first three issues are only partly independent -- we 
cannot say "yes" to #1 without adequate answers to #2 and #3.  But there is 
some independence -- #1 might be disqualified prior to answering #2 and #3, 
and it suffices to have *adequate* answers to #2 and #3 in order to say yes 
to #1.  Having said yes, we can then still try to improve our answers to #2 
and #3.

So, in this spirit, I'd like to propose that we attempt answering #1 by 
imagining the side-effect-free subset of E's current collections, for now, 
as our hypothetical answer to #2.  Many of us are much more familiar with 
this library than with Hydro.  In doing this, let's remember the ground 
rules: a) If this answer to #2 isn't good enough, that doesn't disqualify 
#1 -- we should reexamine using Hydro.  b) Even if it is good enough, and we 
agree with #1, we still proceed to analyze Hydro as an improvement.

Tyler, since you're the only one currently familiar with both, do you see 
any problem with this approach?


         Cheers,
         --MarkM