Side-effect free containers for E

[Ken Kahn]

MarkM wrote:

>
> I believe the "principle of least authority" / "minefield" argument Tyler
> makes is compelling.  The problem is not created simply by the existence
of
> mutable containers.  I pushed us over the cliff when I designed the
mutable
> and immutable containers to share so much protocol, and therefore, to be
so
> interchangeable with each other.  As a result, if a mutable container is
> accidentally used where an immutable one should have been used, the
program
> will often still work under benign and common conditions -- as when
neither
> side mutates the container.
>
> This mistake is easy to make and hard to detect.  As Tyler says,
> (paraphrasing) much of the point of E is to avoid being accident prone
> regarding security accidents.
>

Consider an expert E programmer who is always careful to avoid "accidents"
like this. He or she would probably be glad that MarkM "pushed others over a
cliff" because he/she has a simpler library to deal with since similar
objects share much of their protocol. The learning and cognitive load are
lower as things now stand. Also he/she might appreciate how easy it is to
switch between the mutable and immutable containers.

Perhaps there is another way to help the "accident prone" programmer from
making mistakes without making life a bit harder and less pleasant for the
"careful" programmer who doesn't make these kinds of mistakes. Maybe the
language can be left alone but the programming environment can be enhanced
to help warn about potential "accidents". E.g., many C++ programming
environments give warnings if "=" is used in a context where "==" is
probably what was meant. Perhaps there is a way to give warnings about
usages of mutable containers that probably should have been mutable.

Shifting the burden to the programming environment means that the language
can stay stable and expert programmers needn't suffer.

Best,

-ken