From the HyperSpec, in DEFINE-METHOD-COMBINATION:
"Method combination types defined with the short form require exactly
one qualifier per method. An error of type error is signaled if there
are applicable methods with no qualifiers or with qualifiers that are
not supported by the method combination type. At least one primary
method must be applicable or an error of type error is signaled."
The notion of "applicable method" and "primary method" seem to me to
be valid at dispatch time. Is it then justified to signal an error in
the following case?
(DEFGENERIC DG-MC.APPEND.10 (X)
(:METHOD-COMBINATION APPEND)
(:METHOD ((X T)) '(A))))
Paul's testsuite interprets that, since the method has not the right
qualifier for the method combination, an error has to be signaled when
the method is installed. This is ok for PCL, which is designed
assuming that method combinations are fixed one a generic function is
defined.
ECL, however, supports changing method combinations at run time, and
the error is only signaled when DG-MC.APPEND.10 is invoked. I believe
that the ANSI specification does not penalize this behavior. Am I
wrong?
Best regards,
Juanjo
From: Paul F. Dietz
Subject: Re: Method combinations and DEFMETHOD/DEFGENERIC
Date:
Message-ID: <8H-dnb5by-goDouiU-KYgg@dls.net>
Juanjo wrote:
> ECL, however, supports changing method combinations at run time, and
> the error is only signaled when DG-MC.APPEND.10 is invoked. I believe
> that the ANSI specification does not penalize this behavior. Am I
> wrong?
Your comment seems reasonable to me. I will not be able to change
the test suite until next week, however.
Paul
"Paul F. Dietz" <·····@dls.net> wrote in message news:<······················@dls.net>...
> Juanjo wrote:
>
> > ECL, however, supports changing method combinations at run time, and
> > the error is only signaled when DG-MC.APPEND.10 is invoked. I believe
> > that the ANSI specification does not penalize this behavior. Am I
> > wrong?
>
> Your comment seems reasonable to me. I will not be able to change
> the test suite until next week, however.
No problem, I still have to fix ECL so that a DEFGENERIC form actually
binds a generic function to the symbol, and not the current
DISPATCH-FUNCTION object.
Juanjo
From: Steven M. Haflich
Subject: Re: Method combinations and DEFMETHOD/DEFGENERIC
Date:
Message-ID: <3F176CB7.5040201@alum.mit.edu>
Paul F. Dietz wrote:
> Juanjo wrote:
>
>> ECL, however, supports changing method combinations at run time, and
>> the error is only signaled when DG-MC.APPEND.10 is invoked. I believe
>> that the ANSI specification does not penalize this behavior. Am I
>> wrong?
>
> Your comment seems reasonable to me. I will not be able to change
> the test suite until next week, however.
More to the point, relaize that the ANS says that method combination
runs when a gf is called. (Logically, method combination runs for each
call to the gf, although as they say on the street, "caching happens.")
The ANS doesn't quite _require_ that method combination happens _only_
at gf call run time, but it's pretty clearly implied. Therefore, an
implemenation that signals a method combintion error prior to the gf
being called with actual arguments that trigger the _potential_ error
puts itself in an odd place with regard to compatibility.
-smh
"CLOS is all about late binding.
Some implementers were late realizing this."
From: Paul F. Dietz
Subject: Re: Method combinations and DEFMETHOD/DEFGENERIC
Date:
Message-ID: <Uo6cnQh-kagCKb6iXTWJhQ@dls.net>
Juanjo wrote:
> ECL, however, supports changing method combinations at run time, and
> the error is only signaled when DG-MC.APPEND.10 is invoked. I believe
> that the ANSI specification does not penalize this behavior. Am I
> wrong?
I have modified tests for the builtin nonstandard method combinations
to require late checking (at function invocation time rather than at
function definition time). If there are additional tests that should be
changed please tell me. In particular, I have not yet looked into
the implications for tests on standard method combination.
As I read the spec, it looks like the checking should not occur
if the bad method is not applicable. I have not yet written tests
for this, but plan to do so.
ACL 6.2 passes these tests, SBCL fails on them (as does CMUCL, I think,
but I haven't confirmed that.) Lispworks 4.2 also fails, signalling the
error at generic function (and method) definition time.
I have also begun annotating the tests associated with '(vector nil)
is a string'. These annotations are not yet used to group the test
names in the output of RT:DO-TESTS, but they can be used to selectively
turn off these tests. See rt::disable-note and the file notes.lsp.
Paul