[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue QUOTE-MAY-COPY, version 2
- To: "firstname.lastname@example.org"@multimax.encore.com (Sandra J Loosemore)
- Subject: Re: issue QUOTE-MAY-COPY, version 2
- From: Dan L. Pierson <email@example.com>
- Date: Mon, 12 Dec 88 15:48:45 EST
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Sat, 10 Dec 88 12:12:08 -0700. <8812101912.AA02084@defun.utah.edu>
I also support QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE. In the absence of
overwhelming opposing reasons, we should not diminish traditional Lisp
functionality. While NOT-EVAL may be more in line with current
practice of a couple of implementations, the argument that these
implementations are already broken is at least as strong as the
argument that we shouldn't break them by pointing out that they don't
conform to the language standard.
However, my position on this is not unalterable. I would like to see
a writeup with more discussion that fairly presents both views. As
with so many of the compiler issues, this one has gotten buried in
such a torrent of mail that I can't keep track of all the arguments.
One of the global disagreements seems to be that some members of the
committee want to optimize file compilation at the expense of
incremental compilation. Others, including myself, see incremental
compilation as a very important tool that is potentially key to the
success of large, stock hardware AI applications. Many Lisp
applications write new code as they go along. It is reasonable and
desireable for those applications to compile such code when they
expect it to be executed frequently. It is also reasonable for them
to expect such code to share data structures with other code no matter
what order the data structures and code fragments were created in.
Maybe JonL's recent proposal that QUOTE can copy at most once (i.e.
that all references to (QUOTE FOO) must be EQL to each other even
though they may not be EQL to FOO) satisfies, or sufficiently
minimizes, the above objections, but I'm not sure.