[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: FUNCTION-TYPE (version 3)
- To: Fahlman@C.CS.CMU.EDU
- Subject: Issue: FUNCTION-TYPE (version 3)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 13 May 87 03:10 EDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
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
* 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
* 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
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.