Subject: Re: Newbie question
From: (Rob Warnock)
Date: 3 Apr 2001 04:04:21 GMT
Newsgroups: comp.lang.lisp
Message-ID: <9abi45$6scbt$>
Kent M Pitman  <> wrote:
| (Roger Corman) writes:
| > As I now understand it:
| > Coalescing of literals is prohibited by the standard when EVAL or
| > COMPILE  is used (CLHS 3.2.4).
| Yes, this is because it's not "compiling" per se which is allowed
| to do this but "externalization to a file" that is permitted to.

If this is really true [but see later], then CMUCL would appear to be
violating your reading of 3.2.4:

	* (defun foo () (eq `(0) `(0)))
	* (foo)	; interpreted
	* (compile 'foo)
	Compiling LAMBDA NIL: 
	Compiling Top-Level Form: 
	* (foo)

But does 3.2.4 really prohibit this?  Other than the result of the EQ,
the two lists would not otherwise be observable as distinct "objects
in the source code" [since the bodies of even interpreted functions
are not required to be accessible], so we cannot say whether the objects
being passed to EQ *are* the "same" or not [without running the code].
If they are, then the result is permitted, yes?

Likewise, also because we're not allowed to look "inside" functions,
these should be permitted too, I'd say:

	* (eval `((lambda () (eq ',`(0) ',`(0)))))
	* (eval (list (list 'lambda nil (list 'eq '`(0) '`(0)))))


p.s. Note that even though CMUCL *does* coalesce the values of *A*
and *B* below when file-compiled, it doesn't do so when the same is
typed to the REPL, which is kinda what one would expect:

	(defvar *a* `(0))
	(defvar *b* `(0))
	(defun bar () (eq *a* *b*))

Rob Warnock, 31-2-510
SGI Network Engineering		<URL:>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA