Issue: FUNCTION-TYPE (version 3)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

While I'm sympathetic to this proposal in some form, I can't support
it as currently drafted.

My main problem is that it tries to clarify too many things. The question of
what is a function is logically distinct from that of what may go in the
function cell. I am very excited about clarifying the type issues, but very
nervous about changing what can go in the function cell.

Here are my notes on the proposal...

 * I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
   the meaning and could provoke useless debate about what the difference
   might be between a function and a closure; currently CL has no such
   formal distinction.

 * It seems to me that we might as well go ahead and create types
   INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
   the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
   this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.

 * "behavior" is spelled "behvior" in one place.

 * I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
   synonymous. Please cite a page reference that suggests they are allowed
   to differ. I could not find a definition of the FUNCTION type specifier
   when I looked just now.

 * In item 3 of proposal, I'd say "the text of their description" to be
   completely clear. To me, the descriptions are the abstract entities
   which you've just noted don't need change.

 * Items 4 & 5 are a major incompatibility that I would like to see proposed
   and discussed separately so as not to bog down the type issues which this
   proposal should be about. Macsyma, for example, makes considerable use
   of symbols and lambda expressions in the function cell. Making sure it
   would be happy with this clause would be very non-trivial.

   For now, I would leave this essentially as you left APPLY, pending a
   separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
   return things which are non-functions if those objects can be coerced to
   functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
   and the value later retrieved will be the given object (not a coerced
   form of it), though obviously internally some encapsulation may want to
   go on for stock hardware to make function calling fast.

 * At the in-person meeting at Xerox in March, I suggested that COMPILE
   should not complain if it gets an already-compiled thing, and someone
   pointed out that this could be bad because some users might be wanting
   recompilation and others might want no action. I think we should consider
   a better fix, like something that lets the user say explicitly what
   action to take if the function is already compiled, but for now I would
   leave this an error.

 * The adoption cost does not mention STEP, TRACE, and ED. I think it should.

 * The benefits section should flush the reference to Lisp1, since the only
   criterion for being a Lisp-1 is that you have a unified namespace. In
   fact, this is not properly related to that and mentioning Lisp1 may
   provoke unnecessary worry. It is adequate to say it makes things more
   like Scheme.

 * I believe the conversion cost is potentially much greater than you
   have estimated unless you move items 4 & 5 to another proposal.

   The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
   important consequences to do with the inheritance of new definitions of
   BAR if it is later defined. I think that some people exploit this a lot
   and it may not always be easy to detect.

   The impact on home-grown steppers, trace and advise facilities, and other
   functions which manipulate the contents of the function cell has also been
   underplayed.

Please don't let these comments get you down. It's clear that a lot of work
has gone into this and I'm hopeful that it will be resolved successfully.
I just want to keep the decision process as unencumbered as possible and
right now it's just too hard for me to reason clearly about the overall
impact of such a sweeping proposal.
 -kmp