interp .neq. compil, even in CL

[Robert Elton Maas <REM@IMSSS.SU.EDU>]

  |Date: Wed, 10 Apr 1985  15:16 EST
  |From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
  |
  |    Yep, that's true.  In the hurry to say that compiling code has no
  |effects on its semantics, the CLM glossed over some uglies that are
  |unlikely to go away.

Hear! Hear!

You've brought up several items that ought to be explained in the
manual. It should say something like "Common LISP tries to make the
semantics of compiled programs and the semantics of their interpreted
sources as nearly identical as they can be. But certain processes such
as reading data in or writing it out lose information thereby causing
some differences between interpreted and compiled code: - READing an
s-expression containing unqualified identifiers (those with no
explicit package qualifier) to be assigned to a package at the time
they are read, thus causing compiled identifiers to be assigned to a
package which was default at the time of compiling rather than the
package that is default at the time the compiled code is later read
and executed. To force these two packages to be the same, the
IN-PACKAGE declaration is available (page ...). - When writing two
different s-expressions (using PRIN1 or via compiling and
FASL-writing), information about internal structure they share is
lost. There is no way short of hashcons to maintain that sharing over
a write-read cycle. ..." etc. etc.

This list of differences between interpreted and compiled software
should be summarized all in one place, as above, although details of
IN-PACKAGE and the like can be elsewhere. CLM should realize it has
not totally obtained the goal of interp/compil equivalence, and state
to which degree it has and hasn't succeeded, lest hundreds of LUSERs
discover for themselves (painfully) that we haven't told them the truth.