[plt-scheme] Native code generation and immutable pairs

On Fri, Mar 10, 2006 at 09:42:41AM -0800, Jim Blandy wrote:
> When I call 'list', what sort of list does that produce? When I write
> a variable arity function, what sort of list contains its arguments? 
> When I import SRFI-1 and call 'take' or 'zip', what sort of list do I
> get?

Right. I agree that it would be nice to get these to produce immutable
lists when programming in functional style (as people should). However,
imperative style must also be supported both for backwards compatibility
and because some people may actually have valid reasons for using it.

So we need some way to choose between the two kinds of lists to produce.
One solution would be to make cons choose mutability at run-time based
on a parameter, but this would be inefficient, and it wouldn't really
accommodate combining the two styles in the same program.

The choice needs to be made statically, and thankfully the mzscheme
module system provides a way to do this: just augment the module
resolver so that specially tagged imports are actually mapped to modules
that are linked against a base module where cons produces immutable
pairs.

A problem with this is that if a module is used both as
mutable-producing and immutable-producing, then the same code gets
loaded twice, with just a different linkage. It would be different if
all modules were loaded as mixin components that could be linked
multiple times...

Incidentally, the linear-update procedures of SRFI-1 are pretty well
designed, as they can easily work with both mutable and immutable pairs:
mutable ones are modified, immutable ones are copied and returned. This
is a pretty good style of programming, and I think it would be a good
idea to move towards this with set-car! and other standard destructive
procedures. Perhaps R6RS should specify that they should return the
changed object?


Lauri