Re: Weirdness in Dylan spec

[tar@ISI.EDU (Thomas A. Russ)]

In article ... (Henry Lieberman) writes:

     "If [the current symbol binding] contains a generic function, the
      definition of the generic function must be consistent with the call
      to 'define-generic-function', or and error is signaled"

      This implies to me that typing:

      (define-generic-function foo (x) ...)
      (define-generic-function foo (x y) ...)

      will generate an error.  

   I agree, this is one of the worst mistakes of CLOS, and I would be sad to 
   see it repeated in Dylan. 

   In OO languages such as Smalltalk, Flavors, Actors, etc. the name of
   the "message" [= CLOS "generic function"] is merely a convention
   between the sender and receiver. That is, different sender-receiver
   pairs can use the same name with different argument lists without
   conflict. Forcing global consistency means that choosing a new name must
   take into account all existing names.
	[...]
   Henry Lieberman

The sender and receiver metaphor works well only when all of the
message dispatch is based on the first argument to the function.  It
becomes much hairier when multi-methods are used.  For example,
consider the following:


(defmethod ship ((item package) &rest options)
  ...)

(defmethod ship ((item package) (destination city) &rest options)
  ...)

Being able to distinguish these two methods is very difficult, since
the number of required arguments are different in the two methods.
Since rest arguments are specified, a call to

   (ship some-package some-city)

could potentially match either method.  The person writing the method
call has no way to indicate whether some-city is a required parameter
(and thus available for dispatch) or one of the rest arguments (and
thus ancillary information).  It was to avoid this and related sorts
of problem that the congruence of lambda-lists was introduced for
generic functions.  The more complicated the rules for figuring out
which arguments are used to do method dispatch, the slower the
resulting method call.  At some point, execution efficiency
considerations outweigh the advantages of more flexible functions.

--

Thomas A. Russ                                             tar@isi.edu    
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292      (310) 822-1511