[plt-scheme] Native code generation and immutable pairs

I think the problems come from the prevalence of cons. There are many
primitives that produce cons pairs and many places where cons cells are
used in libraries that could be immutable for nearly every use (and
thus reap those benefits) but the one or two uses where mutable cons
cells are necessary makes everyone pay.

If we had instead, from the beginning, had immutable cons cells and one
would have had to say "mutable-cons" or something like that to get a
mutable pair (and the primitives otherwise produced immutable cons
cells), we wouldn't even be having this discussion and probably
everyone would be happy.

Robby

At Fri, 10 Mar 2006 14:03:09 +0200, Lauri Alanko wrote:
> On Fri, Mar 10, 2006 at 01:22:29AM -0800, Noel Welsh wrote:
> > There is always a tradeoff between changes that improve a
> > language and supporting backwards compatability.  This is
> > one of those cases.
> 
> So you are suggesting changing "cons"? What exactly would this buy? Any
> new code can use immutable-cons, and any existing code can be easily
> changed to use immutable-cons. Changing "cons" directly would only
> benefit pure legacy code that would perhaps become automatically more
> efficient without having to touch the code.
> 
> A change that only makes legacy code more efficient doesn't sound very
> forward-thinking to me.
> 
> I do agree that immutability should be better supported and easier to
> use than it currently is, but that doesn't require
> backwards-incompatible changes.
> 
> What's so horrible about mutable cons cells, anyway? They are just
> two-element structures. Do you want to make structures immutable as
> well?
> 
> 
> Lauri
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme