compiler environment, how best to isolate side effects

[Robert Elton Maas <REM@IMSSS> (this host known locally only)]

H> Date: 16 Jan 86 14:25:13 EST
H> From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
H> We carefully kept all macros defined in a compiled file on separate
H> properties from the normal macro property, ...
H> We found that this confused users no end.

Reasonable argument against Moon's separate-C-property idea, sigh. I
was hoping that would be the method of choice because it's the easiest
correct method to implement.

H> For complex systems, we found that users would normally supply macros,
H> structure declarations, and functions that were used to expand both
H> the macros and structure declarations.  They would get very confused
H> when macro compilation blew up because it couldn't get to functions
H> that they had defined in their core image.

It sounds like your compiler used the C... properties exclusively,
refusing to use normal propertis even when the C... property didn't
exist. My suggestion (perhaps I was unclear) was to have the C...
properties mask the normal properties for the compiler operations on
the file, so if the user happened to define a normal macro or auxilary
function in the normal environment before starting the compilation
task the macro or auxilary function would still be seen unless it was
shadowed by a new definition within the file itself (and would be
shadowed only later in the file after the new definition actually
occurred). Thus the compiler would never "blow up because it couldn't
get to functions ..." as your compiler did. (In the other direction,
the innerds of the compiler and other things running in the normal
environment would not see the C... stuff at all. Perhaps that's the
phrase you saw and misapplied to the reverse case of compilation
seeing normal stuff.)

H> But I suspect that most users would find it easier just to let the
H> compiler use the current Lisp environment.

Remember the problem stated by somebody earlier in this discussion, if
you do that you can't build a new version of the compiler because
macros and auxilary functions being compiled will replace macros and
auxilary functions the compiler is trying to use to conduct the
compilation, causing the compiler to crash. We are trying to find a
bugfix for that problem so that it will be easy to compile compilers
in common-lisp.

H> Then they have the choice of compiling in their current core image, or
H> getting a new one, ...
H> I suspect it would be handy to have a way of making it easy to do
H> that in a subfork.  A function like 
H>   (COMPILE-IN-SUBFORK files-to-load files-to-compile)
H> with some way to keep the subfork around for later compilations.

As was pointed out, on LISP machines and other single-address-space
machines, you can't do that except by discarding the current core
image that may have taken weeks to build up. It would be nice to solve
address-space problems (using "address space" in the general sense of
tag->value mapping such as value cell or functional properties etc.)
within LISP itself without assuming an underlying operating system that
supports multiple virtual machines (forks etc.).

H> Unless I hear some proposal more convincing than those so far, I don't
H> think these mechanisms are ready for standardization yet.

With this I agree. On machines with multiple virtual machines that can
be initialized to have identical memory contents but with
copy-on-write, most users will want the COMPILE-IN-SUBFORK feature,
although compiling a new version of the compiler will take special
care. On other machines without multiple virtual machines the whole
thing will need to be done within LISP itself somehow. The desiderata
(semantics) should be specified, perhaps somewhat like I proposed in
my previous message (compiled file equivalent to interpreted file, no
side effects propagate back to normal environment), leaving the
implementation method for the implementor to pick.

(Another example: I still dislike the insistance that property lists
 be implemented as alternating lists instead of using whatever method
 the implementor chooses. Balanced binary trees for property lists
 would solve a lot of expensive-linear-search problems we were
 discussing a few weeks ago, and the implementor should be able to
 choose ASSOC lists or alternating or bbt or hashtable or whatever. You
 don't need a whole new set of functions, since you can use optional or
 keyword parameters for modifying the existing functions, such as
  (ASSOC key alist) can give you normal ASSOC-list search, while
  (ASSOC key altlist :FORMAT ALTLIST) can force it to handle
 alternating lists if you use them somewhere explicitly, or
  (ASSOC key balbinarytree :FORMAT BBT) can force it to handle balanced
 binary trees, and finally
  (ASSOC key plist :FORMAT PLIST) can give you whatever the
 implementation is using for property lists.
 Likewise (GET symbol key default) et al can be extended to
  (GET bbt key default :FORMAT BBT), (REMPROP altlist key :FORMAT ALIST)
 et al.)

If we can prove mathematically there's only one internal mechanism
that works, then we should set that in concrete in CLtL, otherwise not.

(Opinion of REM)