Issue: LET-TOP-LEVEL (version 1)

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

KCL's variation on DEFUN may not in fact be significant; it appears as
though the special-form version is producing an "optimized" form of
closure, which "knows" that it didn't capture any lexical environment.  
[But I don't really know about this -- someone more familiar with KCL 
should comment further.]

The "top-level" issues, while impacting DEFUN usage, shouldn't be an issue
in DEFUN semantics (or at least, I don't think so).  As you suggest, the
notion of "top-level" needs to be treated in its own right; I hope the
inability to find a complete solution for it won't prevent taking partial, 
useful steps in the right direction.

Perhaps the most disturbing underlying problem is the failure of some
implementation to provide meaningful expansions for CLtL's special forms.
I certainly wouldn't expect such macroexpansions to be limited to the
documented CLtL functions, but having the meaning of them be hidden
underneath an "internal" function is defeating of the reason for having
the macro in the first place.  I'm referring to an expansion like the
example you gave ("special forms in disguise"):

	(DEFUN FOO ...) ==> (SYSTEM::DO-A-DEFUN '(DEFUN FOO ...))

It seems to me that many of the special forms could be documented in such
a way that *if* one were to use the obvious macro expansions on them, then
at worst he would miss out on some little niceity of the programming
environment; he should not be subject to major semantic difficulties.
E.g.,  to the degree that

	(SYSTEM::DO-A-DEFUN '(DEFUN ...))

does something substanially different from 

	(SETF (SYMBOL-FUNCTION FOO) #'(LAMBDA ...))

it should only be in the realm of optional, informational features.

This kind of constraint would allow implementational flexibility while
permitting something useful to be said about "Standards".



-- JonL --