Kent M Pitman  <pitman@world.std.com> wrote:
+---------------
| roger@corman.net (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
	* (foo)	; interpreted
	T
	* (compile 'foo)
	Compiling LAMBDA NIL: 
	Compiling Top-Level Form: 
	FOO
	NIL
	NIL
	* (foo)
	T
	* 

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)))))
	T
	* (eval (list (list 'lambda nil (list 'eq '`(0) '`(0)))))
	T
	*


-Rob

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		rpw3@sgi.com
SGI Network Engineering		<URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA