[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
method combinations changing
- To: Gregor.pa@Xerox.COM
- Subject: method combinations changing
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 17 Jan 90 18:18 EST
- Cc: common-lisp-object-system@sail.stanford.edu
- In-reply-to: <19900117020010.1.GREGOR@SPIFF.parc.xerox.com>
- Line-fold: No
Date: Tue, 16 Jan 90 18:00 PST
From: Gregor.pa@Xerox.COM
As near as I can tell, the spec doesn't say enough about long form
method combinations to make it possible to do any caching of method
lookups in the face of them.
The same comments apply to short-form method combination, of course,
since the operator can be a macro and it never says what happens if
you redefine the macro nor does it say in what dynamic environment
the macro expander function will be called.
Specifically, it doesn't say something like the result returned by the
long form method combination must be a function of only the list of
applicable methods. Not the time of day or anything like that.
88-002R p.1-29 makes it clear that caching is allowed and expected, but
never says what is the key for the cache nor when the cache needs to
be recomputed. I'm sure the intent was as you say, that the result
depends only on the sorted list of applicable methods (or, rather, that
the consequences of changing anything else that the result depends on
are unspecified). I think that CLOS as currently documented is generally
pretty weak about just when a user-defined method for a system-defined
generic function will be called.
Also, we have to deal with restrictions on changing a method combination
once it is defined. As part of Common Lisp, you would think that the
results of any changes are undefined. But, parts of CLOS say what
happens. I think we need a restriction to prevent redefining a method
combination.
I believe the original design of CLOS was that the effect of redefining
anything was undefined, as in the rest of Common Lisp. Later, when
the language was changed to allow redefinition, not all of the document
was updated.
I think it's sensible to treat method-combination types like macros,
namely the language does not specify whether the new or old definition
is used if you redefine it, and it would be useful for a development
environment to provide some assistance when you redefine it. ANSI Common
Lisp defines circumstances under which the old definition of a macro
is guaranteed to be used (I'm not sure why), but I don't see any way
to extend that to method-combination types.