[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dispatching on keywords
- To: Jonathan.Bachrach@ircam.fr
- Subject: dispatching on keywords
- From: firstname.lastname@example.org
- Date: Fri, 13 Nov 92 11:38:08 -0500
- Cc: email@example.com
- In-reply-to: Msg of Fri, 13 Nov 1992 15:59:48 +0100 from Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Date: Fri, 13 Nov 1992 15:59:48 +0100
From: 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.
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
That doesn't fix the problem. The problem is really in the assumption
that keyword arguments that aren't provided by the user must be
assigned a default value. I suggest that: "If it hurts, don't do
that." It is possible to leave such arguments "unassigned" and leave
it to the programmer to detect and assign a default, if desired,
_after_ method dispatch. (BTW, this simplifies detecting optional,
including keyword, arguments that were not provided -- not that it was
particularly difficult in Common Lisp.) Without defaults, keyword
arguments won't change class depending on which method you're
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
The manual says that _lists_ of specializers are compared
lexicographically, not individual specializers. Or are you
introducing an arbitrary disambiguating rule? I'll presume not, since
the ambiguity hasn't been mentioned in your message, and doesn't fix the
problem that was the subject of your message.
In the more familiar lexicographic sort, you compare the first letters
of two words using a predicate like `char<?'. If these first two
letters don't tell you which word should come first, i.e. if they're
equal, you loop to compare the next letters. A lexicographic sort of
lists of specializers would compare two lists by starting with the
first specalizers in the lists, comparing them with a predicate
perhaps called `specializer<?'.
Matt Birkholz Cambridge Research Lab
firstname.lastname@example.org <DARWIN>< Digital Equipment Corp.