[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: DEFINE-METHOD-COMBINATION issues
- From: Patrick Dussud <firstname.lastname@example.org>
- Date: Wed, 10 May 89 15:42:18 PDT
- Cc: Common-Lisp-Object-System@sail.stanford.edu, Cyphers@JASPER.SCRC.Symbolics.COM, SKeene@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: David A. Moon's message of Mon, 8 May 89 22:49 EDT <19890509024926.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
Date: Mon, 8 May 89 22:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here are some questions about unclarities in 88-002R revolving around
method combination, along with my suggested answers. Any comments?
I think I will try to use the eventual resolution of this to improve
the writeup in the ANSI Common Lisp draft specification.
Can CALL-NEXT-METHOD be called lexically within a MAKE-METHOD?
p.2-12 says CALL-NEXT-METHOD can be used in the body of a method defined
by a method-defining form, and 1-22 defines "method-defining form" and
does not include MAKE-METHOD, so I think that CALL-NEXT-METHOD is not
specified to work in MAKE-METHOD. The 2-12 text may have been meant to
exclude methods created with the chapter 3 function MAKE-METHOD-LAMBDA,
but in fact it's clear from the draft of chapter 3 that CALL-NEXT-METHOD
does work in such methods. So I don't really know what the intent of
2-12 was, but I think it would be safe to assume that CALL-NEXT-METHOD
need not be supported in MAKE-METHOD. Example:
(call-method (make-method (or (frob) (call-next-method)))
could be rewritten:
(or (frob) (call-method ,(first remaining-methods)
See additional discussion below.
Does CALL-METHOD use the arguments of the effective method, or does it
use the arguments of the MAKE-METHOD that it was a part of? For
(DEFMETHOD CHANGE :AROUND (X &OPTIONAL (N 1))
(CALL-NEXT-METHOD X (MIN N 0)))
(DEFMETHOD CHANGE (X &OPTIONAL (N 2))
What does (CHANGE T 5) return? A strict reading of the spec says 5,
but my intuition says 0, and 0 is a lot easier to implement.
If this is standard method combination, and there are no other methods,
the effective method is
(call-method <:around method>
((make-method (call-method <primary method>))))
and the target of the CALL-NEXT-METHOD is the MAKE-METHOD.
p.2-11: "The arguments are the arguments that were supplied to the
effective method form containing the invocation of CALL-METHOD."
But this is ambiguous, does "the effective method form" mean the whole
thing, or just the part containing the invocation of CALL-METHOD? If it
had meant the whole thing, I think it would have said "the arguments
that were supplied to the generic function". Also it makes more sense
that once call-next-method changes the arguments, they don't "randomly"
change back to the original arguments. So I think the example returns
0. I propose to change the text on p.2-11 to say "The arguments are the
arguments that were supplied to the innermost MAKE-METHOD-created
method enclosing the invocation of CALL-METHOD, or if there is no
MAKE-METHOD, the arguments that were supplied to the generic function."
I'd like to say this in fewer words, but couldn't think of a way.
I makes sense. I think that is the right thing to do.
Is the effective method code a real Lisp form, i.e. can it contain
forms which require closures, like:
(CALL-METHOD ,(FIRST PRE-METHODS)
(MAKE-METHOD (RETURN-FROM TOO-DEEP NIL))))
(CALL-METHOD ,(FIRST POST-METHODS)
Nothing in chapter 1 or 2 mentions any restrictions on what the
effective method form can do, so the answer should be yes. The
problem is that the description of MAKE-METHOD (p.2-11) fails to
specify the lexical environment of the form its given. Nor does
anything specify the lexical environment of the overall effective
method form. After thinking about it a bit, I believe the intention
was that both of these forms are in the null lexical environment.
Thus the answer is that this example code is not valid.
Unless there are further comments, I propose to change the ANSI
Common Lisp specification to say both effective method forms and
MAKE-METHOD forms are in the null lexical environment. Note that
this implies no CALL-NEXT-METHOD inside of MAKE-METHOD. And no
CONTINUE-WHOPPER inside of a DEFWRAPPER, to translate back to
The only comment I have is that I don't know if it is going to be seen as a
drastic constraint or not. I'd like to see others opinion on this.
In 12/15/88 MOP Draft number 10, some places seem to think that a
METHOD-COMBINATION object consists of the information supplied to
DEFGENERIC (with a mysterious "Documentation" slot), and other places
seem to think that it consists of the information supplied to
DEFINE-METHOD-COMBINATION, but the slots only make sense for the short
I agree with what was said and I don't think we need to change the document.
The issue here is that p.2-34 says "If lambda-list is not congruent to
the generic function's lambda-list, additional ignored parameters are
automatically inserted until it is congruent", but this doesn't say
where they are inserted nor what happens if inserting additional
parameters can't make it congruent (e.g. too many required parameters
to begin with). Are they inserted at the end? At the end of each
group (required, optional, keyword)? At the beginning??
We thought about simplifying this to just require the two lambda-lists
to be congruent, but that doesn't work well since a single method
combination type should be useable with many different generic functions
with different lambda-lists.
I think the best answer is to delete the stuff about congruence (the
last two sentences of the first paragraph on p.2-34) and simply say what
happens if the arguments supplied to the generic function don't match
the lambda-list: if there are too few arguments, NIL is assumed for
missing arguments. If there are too many arguments, the extra arguments
are ignored. If there are unhandled keyword arguments, they are
ignored. Supplied-p parameters work in the normal fashion. Default
value forms are evaluated in the null lexical environment (except for
bindings of :ARGUMENTS parameters to their left, of course). This is
more or less what the equivalent Flavors feature does. Any objections?
Also, what happens if the effective method form returned by your
body forms includes (setq ,variable ...) or (setf ,variable ...),
where variable is one of the :ARGUMENTS parameters? I think
the consequences should be undefined.
All of this sound good.