[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed syntactic cleanups in defmethod
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: proposed syntactic cleanups in defmethod
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 9 Sep 87 16:30 PDT
- Cc: Common-Lisp-Object-System@sail.stanford.edu
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Thu, 20 Aug 87 12:29 EDT
- Sender: Bobrow.pa@Xerox.COM
I propose that the DEFMETHOD macro be specified to "refer to"
(in the sense of CLtL p.160) each specialized parameter.
I think this is a fine idea.
One of the most common mistakes of beginning Lisp programmers
is omitting quote marks or putting them in the wrong place.
Actually, it's not only beginning programmers who do this. I still
do it myself sometimes, and I believe I have seen Danny Bobrow do
it.
I never do 'that'', do I??
The other problem with methods on individuals is that the
current syntax [for defmethod] is awkward when the individual is
anything other
than a symbol or a number
The intent was that for other cases, one would use the add-method form
which evaluates its arguments. However, I don't at all mind seeing a
change that makes defmethod easier to use for this case. And I agree
that evaluating the argument is useful, and using single quote may be a
more error prone as a syntax than a fully spelled keyword.
Of EQL and MEMBER, I prefer EQL since the form (MEMBER X) looks too easy
to extend with a Y and Z. But I would prefer not to suggest extensions
unless we are prepared to follow through on them soon. For this reason
some other word might be better. How about
(THIS x) as being mnemonic and short.
I think that adding QUOTE as a type-specifier to Common Lisp is
both unnecessary and confusing. (Yes, I know I suggested it. I
was wrong.) Instead, the parameter-specializer for a method on an
individual should be (MEMBER object), the type-specifier that
Common Lisp already defines for this purpose. Note that there is
no particular reason why the parameter-specializer should be the
same as the parameter-specializer-name; they're already not the
same for methods on classes.
A problem with this may be that the type specifier is used in the
specializers argument of add-method, and again this could lead to
unwarranted extrapolation. On the other hand, if you are using
add-method perhaps you are immune to unwarranted speculation.