Re: dispatching on keywords

[moon (David A. Moon)]

> Date: Fri, 13 Nov 1992 15:59:48 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> 
> > .... 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>.

I didn't say that <x> inherited from <y> nor vice versa.  Suppose in CLOS we
have

  (defclass <x> (<object>) ())
  (defclass <y> (<object>) ())
  (defclass <v> (<y> <x>) ())
  (defclass <w> (<x> <y>) ())

This gives the CPL's mentioned above.

> 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 CLOS, specializers cannot be sorted according to specificity in the absence
of an argument, because specificity is only defined with respect to a particular
object.  See page 794 of Common Lisp: the Language second edition.

The Dylan book does not specify whether Dylan uses the same rules as CLOS or uses
different rules.

> 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.

There is no class-name function in Dylan, although there is one in CLOS.

By lexicographical order are you saying that the semantics depends on the spelling 
of the variable that is bound to the class?!?  What if there is more than one 
variable bound a given class, for instance in your example suppose someone did

  (define <identifier> <symbol>)

because they like the word "identifier" better.  This is valid Dylan.  Would this 
change which method is applicable?