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

Matthew Flatt schrieb:
> 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. [...]

Hmm, I can accept that reasoning for vectors.

> 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), [...]

I do pass hash tables around as arguments and I'm very happy about the
improved support for immutable ones :-)

>> 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. [...]

I actually like immutability to be the default. I just don't think that
having the mutable pair type extend the immutable one would necessarily
mean to sacrifice all the benefits of immutability while gaining in
interoperability.

> 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. [...]

But I also agree that mutable lists are rarely ever useful. I would even
be happy with the extreme way to solve the interoperability problem:
Simply switch all the dialects of PLT Scheme to immutable pairs. Even
though it's a deviation from the standards, it would probably be less
problematic than the current situation and it would certainly allow the
collection of experience for the future ;-)

cu,
Thomas