Lazy error signaling?

[kab@charon.MIT.EDU (Kim A. Barrett)]

>> Date: Mon, 7 May 90 20:34:40 PDT
>> From: Jon L White <jonl>
>>
>> 88-002R, page 1-30 says:
>>
>>   "In standard method combination, if there is an applicable method
>>    bug no applicable primary method, an error is signaled."
>>
>> Some have interpreted that to mean that it is OK to define an :around
>> method that doesn't call CALL-NEXT-METHOD, since the error signaling
>> in this case should only be triggered when an attempt is made to call
>> the non-existent primary method.  Others take the stricter view that
>> the error should be signaled at effective-method computation time,
>> regardless of whether or not CALL-NEXT-METHOD is involved.
>>
>> Anyone of you out there got an opinion on this one?
>>
>> -- JonL --

> TICLOS takes the stricter view, it signal an error at
> compute-effective-method time. This tends to get supported by the sample code
> of the standard method combination in 88-002R page 2-35. The code clearly
> states that at least one primary is required, regardless of the flow of
> control in the :around method. 
>
> Patrick. 

But the implementation of (... :required t) could be done via binding the
method list to a list of one method which will do the error signaling when
called.  I don't think the sample code is really that strong an argument for
early error signaling here.

One problem with signaling the error at compute-effective-method time is that
it prevents precomputing of combined methods.  I know PCL used to precompute
combined methods and put them into a sort of discrimination network.  For some
of the nodes in the network, it might not be valid to call the function because
no primary method is present.  One way this can come about is when loading a
file which adds methods to a generic function, and there are calls to the
generic function which occur during the load.

I noticed this ambiguity a long time ago, including it in one of my reviews of
the standard (or maybe just of 88-002R), and never heard anything more about it
(like most of my review comments).  For current practice, IIM-CLOS does lazy
signaling via a call to a generic function called NO-PRIMARY-METHOD (which is
analogous to NO-APPLICABLE-METHOD), allowing specialization of its behavior.
An effect similar to specialization of NO-PRIMARY-METHOD can be achieved by
defining specialized method-combination types, but this can lead to a massive
proliforation of method-combination types and generally seemed to us to be the
wrong way to go.
					kab