[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-top-level DEFUN
- To: franz!feast!smh%ucbarpa.Berkeley.EDU@multimax (Steven M. Haflich)
- Subject: Re: non-top-level DEFUN
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Tue, 21 Jun 88 09:30:20 EDT
- Cc: cl-compiler%sail.stanford.edu@multimax.ARPA
- In-reply-to: Your message of Mon, 20 Jun 88 22:36:10 -0400. <8806210236.AA00094@feast>
I wonder if any other implementations will suffer the same problem?
Has anyone yet thought about this? Is the non-top-level-defun change
less compatible than we thought? Obviously, the compiler and
interpreter could be unified, but efficiency might suffer.
Kent pointed this out to me at Fort Collins. The underlying problem
is that if you wrap a closure around a set of top-level forms, you
have to treat the set as a whole for the purpose of compilation.
I think that it's basically a development environment problem. An
implementation that wishes to support incremental development in this
style needs to provide a lexical environment inspector. To RE-compile
one part of a closure, you enter the closure environment and do the
recompile there. Many Scheme systems support such an inspector,
though none that I'm aware of advertise incremental compilation
(T/ORBIT supports it undocumented, but maybe not this feature). A
couple of caveats to this suggestion:
1. It may still be necessary for the entire closure to be either
compiled or interpreted because of environment representation.
2. I am not suggesting making this part of the Common Lisp
standard because we haven't defined what lexical environments
are yet. This is about a possible Common Lisp extension that a
vendor could support; other vendors could just require you to
redefine the entire closure at once, which probably means file
compilation (though it would be nice to get a handle on the LET
and some way to pass it to COMPILE).
All in all, the top level defining forms stuff provides additional
necessary support to an area that Common Lisp copied from Scheme. The
additional support is useful but not complete; however complete
support would have to include a good deal of development environment
support which is out of our area.