[plt-scheme] Native code generation and immutable pairs
From: Lauri Alanko (la at iki.fi)
Date: Fri Mar 10 21:31:19 EST 2006 |
|
On Fri, Mar 10, 2006 at 05:25:15PM -0800, Jim Blandy wrote:
> My goal here is to find some way to allow the compiler to eliminate
> run-time typechecks.
Fair enough. It's not _my_ chosen reason for supporting immutability,
though.
> 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 the problem is that your procedures might receive mutable lists from
the outside world even though it's designed to only operate on immutable
lists? Then its contract has been breached, and we cannot guarantee
anything about its operation anyway. Such a situation should of course
preferrably be detected at run-time.
Also, in many cases, I guess, if a procedure is passed a mutable list,
it can just make an immutable copy of it and use that thereafter.
> 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.
It's just the first step in a plan to gradually migrate to immutable
lists.
R6RS: refine the defition of set-x! to return its argument data
structure. This is completely backwards compatible since currently the
return value is unspecified. Programmers are encouraged to start using
the return value and not rely on the side effect.
R7RS: no longer guarantee, but still allow, that set-x! mutates its
argument. Implementations may choose to stay backwards-compatible, or
they may define set-x! to allocate a new object. Portable R7RS-compliant
code cannot rely on either behavior.
R8RS: guarantee that pairs will not be modified and set-x! will always
return a newly allocated object. This is now a backwards-compatible
change since R7RS allows such behavior.
Also, at some point eq? on pairs needs to be unspecified. Once pairs
have no state, they don't need identity, either.
Lauri