Lazy error signaling?

[Patrick Dussud <dussud@lucid.com>]

   Date: Sat, 12 May 90 11:29:20 EDT
   From: 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.
This is not what the description of define-method-combination says. Since
method combination composition is accessible to the programmer with
DEFINE-METHOD-COMBINATION, it is bacd practice for the implementation to add
obscure system defined methods in places that are visible by the programmer.
The list of primary methods inside of a define-method-combination should be
bound to a list of method either defined by user-code, or supplied by the
implementation when documented as such. 

   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 don't think it prevents precomputing of combined methods. Methods can be
computed at any stage such as compile-file time or while figuring out
effective methods for other argument classes, but could be forgotten at that
time if METHOD-COMBINATION-ERROR is called. This is what TI-CLOS does in some
cases. 

Patrick.