[plt-scheme] Native code generation and immutable pairs

On 3/10/06, Lauri Alanko <la at iki.fi> wrote:
> 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.

If this were all that was necessary, that would be less of a problem. 
Did you read the thread through from the beginning?

My goal here is to find some way to allow the compiler to eliminate
run-time typechecks.  So we're looking for a way, at compile time, to
determine (say) the type of the cdr of a given pair.  If the code
we're compiling will ever be linked against code that does mutation
and runs preemptive threads, and the pair is ever returned to or
received from such code, or referred to by any value that is, then the
compiler cannot be sure that the cdr will not, at any moment, be
changed to some arbitrary value.

Now, if we've consed up a list ourselves, and the compiler can see
every function that has ever touched it, then we're fine.  But those
cases aren't too common.  You'll be spending compile time on an
analysis that isn't going to tell you much.

So it's not enough to simply have an immutable version of SRFI-1 that
Jim's code can import.  You also have to ensure that Jim's code is
never linked into a system that uses mutation and preemptive threads. 
You effectively have two separate languages.  This is fine with me.

> 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?

The definition of the SRFI-1 linear procedures says they are
permitted, but not required, to reuse the pairs in their arguments. 
set-car! is definitely required to mutate the pair it's given.  So I'm
not sure what you mean.