Side-effect free containers for E
Mark S. Miller
Wed, 09 Aug 2000 13:50:40 -0700
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
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
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?