dispatching on keywords

[Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>]

I would like to see specializers on keywords in Dylan.  Although it
might be hazardous to implement Scott Fahlman's proposal, it seems
that adding specializers to keywords is feasible.

David Moon replied to Scott with a reason why specializing on keywords
might be difficult:

> The problem with specializing on missing arguments is that if different 
> methods have different defaults, it may not be possible to sort the applicable 
> methods into a consistent order.  Certainly that is true in CLOS.  Suppose 
> method m1 specifies type <x> and defaults to an instance of <w>, while method 
> m2 specifies type <y> and defaults to an instance of <v>.  Now suppose the CPL 
> of <v> is (<v> <y> <x> <object>) and the CPL of <w> is (<w> <x> <y> <object>).
> Is m1 or m2 more specific?  This is why CLOS doesn't allow specializing 
> optional and keyword arguments.  Dylan doesn't actually specify the full set 
> of rules for finding the most specific method yet (see p.82 of the Dylan 
> book), so perhaps we could jigger the rules to make your proposal work.  But 
> there are obvious dangers in that.

I don't understand how <x> can inherit from <y> while <y> inherits
from <x>.  This is not a proper class heterarchy.  What am I missing?

David Moon goes on to state why it would be hazardous to adopt Scott's
proposal, but he does not state a reason which would preclude adding
specializers to the current keyword system.  On the contrary, he says
`perhaps we could jigger the rules'.  Well then, here is my attempt to
`jigger the rules'.

When all keyword values are specified, the most specific method is
chosen just like with required parameters.  When a particular keyword
value is not specified, the keyword's specializers (from the list of
applicable methods) are sorted according to specificity and then
lexicographical order.  

In the following quote, David Moon gives another example of why it's
difficult to specialize #key parameters:
      
> The problem is the unclear semantics of allowing specialization of parameters 
> that are optional, i.e. that are defaulted if the caller does not supply a 
> corresponding argument.  Consider this example (using an invented syntax for 
> specializing keyword parameters that is probably not right):
> 
> (define-method f (#key (a: 100 <integer>)) "method 1")
> 
> (define-method f (#key (a: 'foo <symbol>)) "method 2")
> 
> (f a: 15) => "method 1"
> (f a: 'x) => "method 2"
> (f) => what??

My answer is:

(f) => "method 1"

because (class-name <integer>) < (class-name <symbol>) in
lexicographical order.

I must say that I think that this is a rather contrived example and
that user's shouldn't design and use code such as this.  But
nonetheless, there is a formal rule that describes the
most-specific-method. 

I would think that the required parameters should specify the
most-specific-method and that the specializers on the keywords are
useful for type declarations.

I think it is indispensible to allow specializers (type declarations)
on keyword parameters and if people don't like my proposal, I strongly
encourage them to try their hand at jiggering the rules.

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-42772492
bachrach@ircam.fr