[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
- To: Sandra J Loosemore <email@example.com>
- Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 11 Jan 89 12:53 EST
- Cc: John Rose <jrose@Sun.COM>, Gray@DSG.csc.ti.com, firstname.lastname@example.org, Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: <8901111611.AA12297@defun.utah.edu>
Date: Wed, 11 Jan 89 09:11:57 MST
From: email@example.com (Sandra J Loosemore)
Just to set the record straight:
> Date: Tue, 10 Jan 89 19:03:49 PST
> From: jrose@Sun.COM (John Rose)
> File-level EQ preservation works to restore the embedded
> object reference "for free".
Unfortunately, we don't know yet if file-level EQ preservation works;
see issue CONSTANT-CIRCULAR-COMPILATION. KCL is one implementation
where COMPILE-FILE/LOAD does not now preserve EQness of structures.
If file-level EQ preservation is punted, MAKE-LOAD-FORM only returns one
value, and this whole discussion is punted. So it doesn't actually
matter that we don't know yet (except that we might be wasting our
Personally, I think file-level EQ preservation is important and would
hate to see it excluded from the language specification.
To throw a digression into the discussion, the only thing I know of
that's hard about file-level EQ preservation is EQness of CDRs in
implementations with cdr-coding of lists. Even that's only "hard" in
the sense that it is difficult to convince implementors to do EQness
checking by treating each individual cons as a separate object, rather
than treating the whole list as a single object, because it seems (and
in fact is) less efficient. Symbolics Genera 7.x gets this wrong. What
about the TI Explorer?