On Mar 24, 7:59 am, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> 2009/3/24 Konrad Hinsen <konrad.hin...@laposte.net>
>
>
>
>
>
>
>
> > On Mar 24, 2009, at 11:19, mikel wrote:
>
> > > Dispatch is wholly deterministic; you never need prefer-method. There
>
> > Then what is the rule for choosing one method when there are several
> > that match the arguments?
>
> > > In the scope in which a generic function is applied, next-method is
> > > always bound to the next applicable method in a total ordering of
> > > applicable methods for the arguments supplied (see the first
> > > java.lang.Integer method below for an example of how to use next-
> > > method). applicable-methods is always bound to a function that returns
> > > a list of applicable methods, ordered from most- to least-specific;
> > > next-method is equal to (first (applicable-methods)).
>
> > So I guess that the chosen method is the first one in the applicable-
> > methods list, meaning the "most specific" one. The question is then
> > how "specificity" is defined, in particular for multiple argument
> > dispatch. Suppose in your example that I provide
>
> > (define-method add [x y] ...)
> > (define-method add [[x java.lang.Integer] y] ...)
> > (define-method add [x [y java.lang.Integer]] ...)
>
> > and call (add 3 3). Which of the methods is chosen?
>
> Isn't it the second, which is the most specific on the first argument ?
> (I think I remember this from CLOS ...)
That's correct.
The default dispatch algorithm follows CLOS rules, which are just as
you say. In CLOS, the default dispatch algorithm is the only one,
unless you use MOP features to make a different kind of generic
function. I've been intending to permit you to pass a dispatch
function to define-generic-function if you wish, but it's not
implmented yet. We'll see if I get around to it; I haven't needed such
a feature yet in around twenty years of using CLOS and its immediate
predecessors, but if someone were really hot on having it, that might
make up my mind to implement it.
It's noticeably slower than Clojure's MultiFn dispatch, which is in
turn noticeably slower than Clozure Common Lisp's generic functions.
There's certainly room for optimization, if it turns out to be useful
enough to warrant it.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
