Version 1, March 1993
Sometimes it is not clear which of two methods is the most specific for a particular function call. This is a particular problem for non-class types because it is possible for an object to be an instance of two disjoint types, such as (limited <integer> min: 0) and (limited <integer> max: 10). This design note requires Dylan to signal an error in such cases.
See Dylan Design Note #5: Regularization of the Type System for Dylan's general type system, including types that are not classes.
Add the following section to the Dylan manual's chapter on Functions:
Method Dispatch Ambiguity
Sometimes it is not clear which of two methods is the most specific for a particular function call. This section does not address what happens when t1 and t2 are both classes; it applies when either t1 or t2 or both is not a class.
If f is a generic function having methods m1 and m2, we say that it is ambiguous which of m1 and m2 is the most specific when all of the following are true:
? (define t1 (limited <integer> min: 1 max: 10)) ? (define t2 (limited <integer> min: 0 max: 7)) ? (define x 3) ? (define-method f ((a t1)) 1) ? (define-method f ((a t2)) 2) ? (define-method f ((a (singleton 5))) 'five) ? (f 3) ;error ? (f 0) 2 ? (f 8) 1 ? (f 5) five ;the ambiguous methods are applicable but not called
Notes:
The Dylan book doesn't say what happens in this case (page 82 only addresses the case where one specializer is a singleton or a subclass of the other). We needed to define how Dylan should handle these cases, or we couldn't coherently add more non-class types to Dylan. CLOS has a rule defining how to choose one method as more specific, using the class precedence list based on the order in which multiple superclasses are listed in the define-class, but the rule does not extend nicely from classes to parameterized types and has frequently been criticized as obscure and unhelpful. By requiring Dylan to signal an error, we prevent programmers from depending on what is essentially an arbitrary choice.