Summary of message on function objects & :allow-other-keys

[Alan Bawden <ALAN @ MIT-MC>]

:allow-other-keys sounds ok to me.

    Date: Tuesday, 10 May 1983, 17:12-PDT
    From: BENSON at SPA-NIMBUS

    The first argument to APPLY or FUNCALL (for which FUNCTIONP is
    true) must be a compiled-code object or a lexical closure.  Anything
    else is an error.

I would object to this.  I certainly agree that there is an inelegance in
allowing symbols to serve as functions when passed as arguments to APPLY
and FUNCALL (Algol 68 would be proud of a feature like this), but this is
not an inelegance with any far-reaching consequences (assuming we clarify
the manual about the term "closure", which it does tend to use rather
randomly), and it is a traditional convenience supported by most of Common
Lisp's ancestors.

I don't see any compelling reason to introduce an ENCLOSE function, or to
make environments first-class data objects.  The latter seems like a
unnecessary constraint on implementors.  (I might go for an ENCLOSE like in
the Scheme "Revised Report" that takes a \representation/ of an
environment, but I still don't see the need for it.)

A function to retrieve the lambda-expression from a closure also seems to
me to be assuming a bit to much about the internals of a closure (why
should that information still be there?  What happens if it is a \compiled/
closure).  I presume each implementation can provide rational debugging
facilities to allow me to determine just where a closure originated.