[plt-scheme] Mutable and immutable pairs in PLT Scheme

At Wed, 26 Nov 2008 02:05:57 +0100, Thomas Chust wrote:
> However, the same problems that can be caused by mutable pairs can be
> caused by mutable vectors or hash tables being passed to a procedure
> that doesn't expect the incoming data to change.

True, but I think functions that consume a vector and expect it not to
be mutated are quite rare. When a function accepts or produces a
vector, I think it's much more common that the consumer is expected to
mutate the vector. (I have not actually checked documented libraries to
see whether that's the case; if someone is interested enough to check,
please let us know what you find.)

The case for hash tables is less clear. I think it's rare for a hash
table to be either an argument or result, but maybe it should be more
common (instead of using an assoc list, for example), and probably many
cases should use immutable tables. Such suspicions let us to to expand
support for immutable hash tables in PLT Scheme v4.0.

Overall, as the blog post tries to say, it's all about what is in the
programmers mind. Speaking for myself --- and I imagine that I'm
typical in this respect --- "list" usually says "functional" to me,
while "vector" usually says "imperative". That's why it's important for
lists to be immutable while vectors can be mutable.


> If programmers
> have to be protected from themselves when using lists, why don't they
> need the protection any longer as soon as they start using hash tables?

This, perhaps, is the main difference in our perspectives. I don't see
these constructs as protecting me from myself, but instead as
protecting me from other programmers who call my functions.

This defensive perspective is probably different from a traditional
Lisp mindset --- especially as compared to the Lisp machine, where
users expect to be able to change anything, anywhere. I note that my
perspective affects a lot of my work on PLT Scheme, not only with
immutable pairs, but also custodians, eventspaces, and designs for
"kill safety", so I won't be swayed easily. :)


> I would still vote for interoperability between modules written
> in different languages

Exactly. And until the Scheme community has more experience with
always-immutable pairs, votes will (and should) always fall on the side
of mutable pairs.

But how will the community that produces R7RS know whether immutable
pairs are a good idea or a bad idea? If we continue the compromise on
pairs in the PLT Scheme languages, then not only will PLT Scheme
continue to suffer (at least in the implementors' opinion), but we'll
all continue to just guess about whether it would work.

Meanwhile, settling on immutable pairs certainly sets up an
interoperability problem that we have yet to solve. I rank experience
with immutable pairs over avoiding the interoperability problem; on
this point, too, we may have to agree to disagree.


Matthew