Issue: SETF-PLACES (version 1)

[Jon L White <jonl@lucid.com>]

re: But if you are going extend the lowest level primitives, FBOUNDP and
    SYMBOL-FUNCTION, to accept function specs, then I don't see that you
    gain very much by saying that higher-level macros and special forms
    won't accept them.  ....

That is not the proposal.  In fact it is to _retract_ the CLOS imposed
requirement that every implementation's version of FBOUNDP and
SYMBOL-FUNCTION has to accept function specs.  Only implementations
which already allow DEFUN etc to admit functions specs will have to
change their FBOUNDP and SYMBOL-FUNCTION accordingly; this would be true
regardless of whether we accept SETF-FUNCTION-VS-MACRO or SETF-PLACES.

    If the intent is to limit the amount of change to implementations that
    don't already support function specs, it seems like it would be easier
    to leave FBOUNDP and SYMBOL-FUNCTION alone, introduce FDEFINEDP and
    FDEFINITION, and then say that DEFMETHOD, DEFGENERIC, etc. use
    FDEFINITION instead of SYMBOL-FUNCTION.  

I considered that, and rather liked it, but didn't find much support for
it amongst others (Patrick was, I think, the main opponent; but I don't
think Gregor liked it either).  Either way, we would have to change the
CLOS spec.  In one case [the setf-places proposal] we would have to replace
(FBOUNDP ...) in the CLOS spec by (FBOUNDP (UNDERLYING- ...)), etc., and in 
the other case we would have to to [1] Add new functions FDEFINEDP and 
FDEFINITION, and [2] replace (FBOUNDP ...) in the CLOS spec by 
(FDEFINEDP ...) etc.


re:     The next question is whether there is really a
    need for the user to know about UNDERLYING-NAME.  The only use I can
    think of would be to do a GET on the underlying symbol, or to use it as
    a key in an EQ hash table, but neither of those would be portable since
    UNDERLYING-NAME could return a non-symbol on some implementations.  

I don't forsee any reasonable portable use of UNDERLYING-NAME for the
end  user; its existence is primarily to expose the barrier between the 
surface syntax of setf generic functions and the implementation-specific 
way in which hooks into function definition.  The end user will be using
CLOS primitives.   UNDERLYING-NAME is aimed at sub-system implementors,
especially at the PCL implementor/maintainer, so that his code can be
portable.  But since any implmentation that doesn't support true
functions specs will have to have some such mapping (the "underlying"
name), it might as well be a standardized function to access it.


re: > Looking ahead, I see that several more of the "Brothers-..." have
    > made the same request, which basically boils down to requiring all
    > implementations to have the essence of function specs by "trojan horse".
    But I've just shown you how to implement the essence of function specs
    in only eleven lines of code.  Well, make that thirteen because you
    probably want this too:

With all due respect David, you've shown how to implement function specs
for DEFUN.  The original SETF-FUNCTION-VS-MACRO listed 18 Common Lisp
constructs that would have to be changed, and that doesn't count the
pain for the several portable code-walkers running around.  DEFUN is the 
easy one, because it generally is just a macro (as DEFMETHOD is a macro). 
At any rate, the killer objection is not how much or how little work it is 
to implement function specs, but rather that there is still an enormous 
undercurrent of distaste for list-as-function-names.


re: But if you accept lists to name functions in certain contexts, how does
    it really help to say that they aren't "function specs"?  Since I'm
    obviously coming from a very biased perspective, I don't see anything
    un-esthetic about using lists as function names.  It's certainly a
    concept that has been around a long time and has proven very useful.

To say that the way you incrementally define the setf method for a
generic function is by use of a form like (DEFMETHOD (SETF foo) ...)  
is not by itself acceptance of lists-as-names.  One can pretend that 
this is just a macro that expands into (DEFUN SOME-SYMBOL ...)
[along with whatever implementation-dependent processing is needed to
distinguish generic functions from regular ones].  The difficulty
arises when you require something like (SYMBOL-FUNCTION '(SETF foo))
to have meaning; for those implementations without function specs,
this is the uncrossable barrier.  The current setf-places proposal
neatly puts in the little "fence" by saying:
	(SYMBOL-FUNCTION (UNDERLYING-NAME '(SETF foo)))
An implementation that already has function specs isn't affected at
all by this, since it is permitted to define UNDERLYING-NAME as the
identity function.



-- JonL --