Re: proposed syntactic cleanups in defmethod

[Gregor.pa@Xerox.COM]

I have certainly been bothered by the same problems with defmethod
syntax you address, but I am not sure about all of these solutions. What
is bothering me is that while they all provide convenience, they make
the defmethod form itself more complicated.  I haven't yet made my mind
up, but I thought I would send out a message to at least say something,
since you said you hoped it could be resolved quickly.

The proposal to make defmethod forms, which actually name specializers
for arguments, refer to those arguments certainly would be convenient.
There are a lot of cases in PCL code where I could remove declare
ignores.  But it makes the defmethod story more complicated.
Particularly, if arguments which are not specialized are also refered
to.  I am not sure this is worth the tradeoff?  But I am not sure it
isn't either.

The second proposal (to evaluate the argument to an EQL or ' specializer
at load time) addresses a much more real problem.  In paricular, without
this, its not possible to use call-next-method inside of methods on
individuals.  That probably makes this worth doing, even it it makes the
defmethod story more complex.

I have no particular opinion on the third proposal.

I would like there to be a simple, clean story which can be used to
correspondence between any given defmethod form, and a call to
add-method, make-instance and ensure-generic-function.  Thats what makes
defmethod nice syntax for add-method the same way defun is nice syntax
for setf of symbol-function.