[plt-scheme] Native code generation and immutable pairs

From: Jim Blandy (jimb at red-bean.com)
Date: Sat Feb 11 21:18:36 EST 2006

On 2/11/06, Robby Findler <robby at cs.uchicago.edu> wrote:
> At Fri, 10 Feb 2006 00:07:55 -0800, Jim Blandy wrote:
> > If MzScheme is heading down the native code generation route, have you
> > thought much about making pairs immutable?
> I don't know if anyone answered your question, but yes. We are
> considering that and have been for a long time. Partly because it
> improves analyses like you suggest, but more because it makes it easier
> to reason about programs using immutable conses (and contract systems
> work better when structures are immutable). In particular, you can hand
> out the same list multiple times from a library without having to worry
> about copying it to be safe/correct.

Exactly.  I've been thinking about code generation a lot, but more
immediately I was trying to write, very unambitiously, a list length
function that could be used on untrusted data.  So it tolerates
improper lists and cyclic lists... but there's really nothing
practical you can do about simultaneous mutation.  There's no real way
to promise you won't diverge.

When you realize that mutable pairs and preemptive threads make it
possible for you to make a simple promise like, "I will return you the
length of this list, or an indication that it's not a proper list," it
really makes you want to re-think the big picture a bit.

> (Note that there are already immutable cons's in mzscheme -- it's
> really a question of which kind of cons cell does `cons' (and read and
> ...) produce.)

Right, and SRFI-1, and ...   This is why, "Oh, we've got immutable
pairs!" isn't really a sufficient answer.  (To be clear: I'm not
attributing that answer to you; folks here seem to be on the same
wavelength as I am about this.)

Posted on the users mailing list.