[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: LOAD-OBJECTS (Version 3)
- To: "Richard P. Gabriel" <rpg@lucid.com>
- Subject: Re: Issue: LOAD-OBJECTS (Version 3)
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Mon, 13 Mar 89 19:24:29 CST
- Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu
- In-reply-to: Msg of Sat, 11 Mar 89 16:46:51 PST from Richard P. Gabriel <rpg@lucid.com>
- Sender: GRAY@Kelvin.csc.ti.com
> I was a little surprised to see that this proposal talks about load
> forms instead of load functions (which goes to show how much I've been
> paying attention).
One advantage of sticking with the load form approach is that it has
already been implemented and demonstrated to work.
> I think people will find the macro approach (the current approach)
> baroque, partly because the approach is best understood by thinking of
> an input phase to a compiler or some such program, rather than by
> thinking about an output phase when everything has already been supposedly
> created. For example, when I read the current proposal, I imagined it
> in the FASDUMP phase.
Think of it as input to the loader.
> One drawback of my proposal is that the function approach is a little
> more verbose in some cases. I also think it is subject to more
> circularity errors by novices than the macro approach. On the other
> hand, the functional approach makes one think about the issues a
> little harder when writing the code, which is possibly a good thing.
This sounds like a clear disadvantage, without a clear advantage.
> ;; Example 3 (expanded to do a hairy thing that cannot be easily done
> ;; in the macro approach).
...
> One can imagine the shared lexical environment of the creator and initializer
> being a high-bandwidth channel for information, such as the important
> information passed in the above example.
This example illustrates the following assumptions about dumping
constants:
1. Lexical closures can be dumped and loaded.
2. Two closures that share the same environment at compile-time will
also share the same environment at load time.
3. The lexical environment as reconstructed by the loader is not
write-protected (meaning that closures are not really constants).
4. It is safe to assume that none of the closed-over variables are
changed between the time the first closure is dumped and the time
the last closure that shares that environment is dumped.
It could be argued that all of these would be desirable, but I think
it's a little late to be biting off that much.