Side-effect free containers for E

[Ken Kahn]

MarkM asked:
> >Why not?  For what cases do mutable containers dominate?  This is the key
> >question.  What if we banish mutable containers from the library
documented
> >and promoted for normal use?  What do we lose?
>

And Bill Frantz wrote:
> Can't I always make a mutable container object by building an object that
> uses an immutable container internally, but presents a mutable interface
by
> always using the most recently produced immutable container to perform a
> given function?
>

I agree.

To answer MarkM's questions - with a clever enough implementation immutable
containers have no run-time performance disadvantage over mutable containers
when used in equivalent ways. The immutable containers are more flexible and
when that extra flexibility is used there is some overhead but it can be
kept pretty low. The extra flexibility arises when the code holds references
to both the original and updated versions of the container. I guess what I'm
saying is that if the implementer of the compiler and run-time is willing to
do the extra work, that I can't think of cases where mutable containers
dominate.

Though, as is the case with many compiler optimizations, there is the risk
that programmers who don't understand these optimizations will be surprised
how what they think are small changes to the code results in huge changes in
speed and memory usage.

Best,

-ken