[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Immutable code and quoted data

The area of immutable data for Scheme is a good one for experimentation.
But I don't think Scheme should take a stand on this subject at this
time.  The trick is to phrase the report in such a way as to allow
latitude for people to play around with these ideas.

My main motivation at this point (now that I see there's no consensus)
is that I don't want anyone's implementations to have to change in order
to support EQV? and QUOTE as defined in the Scheme report.  My proposed
EQV? and QUOTE specifications ALLOW implementations to create immutable
structure and have EQV? (and even EQ?) compare the contents of immutable
structure; but they don't REQUIRE them to.  It is probably compatible
with most Schemes in existence, because it is so noncommittal.

It sounds like you're trying to make the language more concrete.  If a
stand is taken one way or another, then no matter which stand is taken,
some implementations will have to change.  If quoted structure must be
mutable, then T, and I suspect some other implementations, including any
implementation embedded in Maclisp or Common Lisp, will have to go to
some trouble to avoid using the obvious existing mechanisms.  If it must
be immutable, you'll also be cursed by implementors who need to add
immutable types and more complicated type checking.

Saying that it is an error if structure created by QUOTE is clobberred
is much weaker than saying either that implementations must have an
IMMUTABLE? predicate or that quoted structure must be mutable.  Errors
do not have to be detected.

I don't see why it makes sense to distinguish interpretation from
compilation.  Scheme has no way to distinguish these situations.
Remember that there is no EVAL, and there's no guarantee that the
mechanism which causes programs to be executed uses READ - it parses the
program somehow, but READ has nothing to do with that.

I think it would be reasonable to argue that READ should be allowed to
return immutable structure, but I'm not going to do so, because I think
some people disagree and I don't feel strongly about it.  But again,
QUOTE and READ are unrelated, since there's no EVAL.  It doesn't make
sense to talk about "copying the source" since source only exists in
files.  If there were an EVAL, I would certainly want it to copy both the
code and the quoted structure (if those things were mutable), to ensure
compatibility between EVAL and transduced (compiled or whatever) code; I
think we agree there.

I agree that if immutable structure exists, then some mechanism besides
QUOTE should exist to create it.  (Maclisp's solution is to have a
single function, PURCOPY, which makes a pure copy of an impure
structure.)  I also agree that immutable structure shouldn't contain
mutable structure and shouldn't be circular (although I doubt that there
would be consensus on these questions - various functional languages out
there let one create circular immutable objects using LETREC).  But I
wouldn't want to force these things on implementors; again, this area is
too borderline and experimental.

(A propos rarity of constant data structures: Algol 68 certainly has all
kinds of constant data.  Also, I was under the impression that C
implementations were allowed to put in-line strings constants in pure
(text) memory.)