[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue QUOTE-MAY-COPY, version 2
- To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
- Subject: issue QUOTE-MAY-COPY, version 2
- From: Jon L White <firstname.lastname@example.org>
- Date: Wed, 21 Dec 88 23:18:10 PST
- Cc: @cs.utah.edu:sandra@defun, email@example.com
- In-reply-to: Jeff Dalton's message of Sun, 18 Dec 88 01:08:17 GMT <firstname.lastname@example.org>
re: > ... To me it seems pretty clear that any copying
> of constants that goes on happens as a result of transforming an
> arbitrary data structure into a program.
Why are the constants transformed at all? I can see why the
program text (i.e., the list) might be transformed. The compiler
might compile it, the interpreter might macroexpand it or partially
compile it. But, unless some writing to a file is involved, why
would any processing be done to the constants?
The basic flaw we have been having in this discussion is that whenever
someone proposes "Let QUOTE have semantics **as if** it made a copy",
then someone else reads that to be saying "QUOTE must necessaryily
copy its argument". The quote (no pun intended) you have from Sandra's
msg is really in the form of a conditional "IF quote makes a copy, then
it can only happen under such-and-such a set of circumstances."
The issue that QUOTE-MAY-COPY is proposing is merely to **defeat** the
counter proposals QUOTE-MUST-NOT-COPY; or QUOTE-MUST-PRESERVE-EQLness.
It is not to say that any implementation ever has to do any copying.
I read Cris's comments as saying that QUOTE-MAY-COPY is the only
consistent interpretation, because even if an implementation of QUOTE
itself never does any copying, the semantics of the result will be
forced to be "maybe is a copy" by other constraints (such as
consistency with file compilation). I think you yourself even
acknowledge this point later in your msg.
-- JonL --