function specs

[BENSON at SPA-Nimbus]

I believe that function specs were not included in Common Lisp because
of the number of issues which they raised.  I don't believe there were
any strong objections to the concept itself, rather to the secondary
consequnces of including them, such as:

It is a pervasive language feature, comparable to type specifiers in
scope, which would require a similar amount of explanation.

It adds yet another semantic interpretation of lists, which conflicts with
some existing ones, e.g. #'(lambda ...) and #'(:property ...) have very
different meanings.  It also means that lists need to be used where only
symbols are now allowed, such as in RETURN-FROM block names.  This may
require changing some equality tests from EQ or EQL to EQUAL.

For consistency, ((:property foo bar) x) should be legal as well as
(funcall #'(property foo bar) x).  This is not currently the case in
Zetalisp.

Despite these problems, I think that function specs probably should be
included in Common Lisp in the next edition, if we can stand another round
of discussion on something as fraught with peril as this.  They are
quite useful.

Regarding another point in your message, it is very unfortunate that
#'(lambda ...) forms not inside defuns are not compiled.  For example,
one might store functions in a hash table rather than on the property
list of a symbol.  A command processor might use an array of functions
indexed by character codes.  There is no function spec which refers to an
entry in a hash table or an element of an array.  This forces one into
your Option 2 kludge if you want the function to be compiled.

-- Eric