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

From: Thomas Chust (chust at web.de)
Date: Tue Nov 25 20:05:57 EST 2008

Robby Findler schrieb:
> Please read Matthew's blog post on the subject. It contains the answer you seek.
> 
> http://blog.plt-scheme.org/2007/11/getting-rid-of-set-car-and-set-cdr.html
> [...]

I see, it's all about predictability and safety. And I fully agree that
using immutable data structures by default helps to achieve these
properties and is a good idea in many cases.

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.

One can guard against such problems. For example by using contracts like
 (and/c immutable? ...) for the procedure arguments in question. But
this would work with pairs as well, if immutable? (or some additional
procedure made for that purpose) scanned list structures recursively to
check for immutability of every node; or if immutable lists were not
allowed to contain mutable tails...

It's less the fact that mutable and immutable pairs are disjunct types
that bites me, it's the asymmetry between the pair types and all the
other aggregate types. Why is hash-map allowed on mutable hash tables
but map is not allowed on mutable lists, for example? 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?

I'm not convinced, yet, that this asymmetry is in any way necessary or
useful. I would still vote for interoperability between modules written
in different languages instead of extra protection from myself ;-) If
the extra protection is absolutely necessary, why is it only implemented
for one data type? Or would you say that the other mutable aggregate
types should be changed as well to be disjunct from their immutable
counterparts?

cu,
Thomas


Posted on the users mailing list.