Re: dispatching on keywords

[kab (Kim Barrett)]

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

There is nothing in Moon's example that says <x> and <y> have any direct 
inheritance relationship at all.  The CPL's he gives could come about from the 
following class definitions (assuming something like CLOS cpl computation rules):

  (define-class <x> (<object>))
  (define-class <y> (<object>))
  (define-class <v> (<y> <x>))
  (define-class <w> (<x> <y>))

> 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 see no class-name in Dylan.  Classes are anonymous objects.  The fact that some 
namable variable is bound to the class has no effect on the class itself.  (Also 
note that the module system allows one to "rename" variables, rendering such an 
ordering to be completely arbitrary anyway).  I can think of other objections, but 
I don't think its worth the time to write them down just now.