2009/3/26 Konrad Hinsen <konrad.hin...@laposte.net>
>
> On 26.03.2009, at 14:59, Rich Hickey wrote:
>
> > Plus the inability to dispatch on other than class or eql, the
> > inability to superimpose another taxonomy without redefining the
> > class, the inability to have multiple independent taxonomies...
>
> The ability to have multiple taxonomies is indeed very useful in my
> (limited) experience.
>
> > One is left-to-right argument order precedence, which roughly
> > translates to vector precedence in Clojure (although the mapping to a
> > vector need not follow arg order).
>
> I am not sure I'd want such a precedence. If I dispatch on several
> arguments, their role is sometimes symmetric, sometimes not, and
> where it is not, it is not necessarily the first argument that takes
> precedence.
>
> However, what I wished I had on some occasions is a way to specify a
> sequence of dispatching values as a result of the dispatch function.
> For example, in a two-argument dispatch, I'd like to be able to write
> something like
>
> (defmulti foo
> (fn [x y]
> (let [tx (type x) ty (type y)]
> (list [tx ty] (cond (isa? tx ty) ty (isa? ty tx) tx :else #{tx
> ty})))
>
> with the result of calling a method for [tx ty] if available and one
> of tx/ty/#{tx ty} otherwise. Without such an option, I sometimes have
> to write several methods with an identical implementation but
> different dispatch signatures.
>
> One way to make this and other generalizations possible would be to
> have access to the multimethod's implementation list (and perhaps
> preference order) in the dispatch function.
>
> > What I like about preference declarations is that you are
> > acknowledging a definite ambiguity in a pure derivation hierarchy
> > rather than poisoning the notion of hierarchy with directionality.
>
> What I like about them is that an ambiguity often points to a design
> problem that should better be fixed than circumvented.
>
> > That said, perhaps the preference specifications at the method level
> > aren't as reusable/convenient as preferences declared at another level
> > or somewhere else.
>
> How about a preference function on each multimethod, along with the
> dispatch function? One could then easily use one such function for
> several multimethods. But what I suggested above (access to the
> dispatch signatures and preferences in the dispatch function) should
> be even more general.
I wanted to write something along those lines, but you Konrad did this
better than I could have done :-)
Though I don't have any concrete need currently:
Am I the only one to have the feeling that the current functionalities
provided by multimethods are too tied with the idea that the dispatching
will be based on type hierarchies ?
I think the current implementation closes the door to a lot of possibly
interesting experiments/applications, because, as Konrad said, both the way
the mechanism of discovering candidate methods, and the way to disambiguing
them is somewhat hardcoded for a certain vision of type hierarchies.
The current implementation, while maybe a good default (I don't have strong
arguments against or pro for saying it is the right default mechanism) could
certainly be just an implementation of a redefinable more generic solution.
The way I understand it, the algorithm for discovering candidate methods is
1- compute a value from the arguments of the call,
2- and then determine for each method's declared dispatch-value if it is a
relevant candidate
Why not make the behavior of 2- user redefinable in the defmulti declaration
?
Such a method could have the following definition :
(fn [computed-value dispatch-values])
This method could return either nil (then a method with a default
dispatch-value would be searched as usual), either a list of candidate
dispatch-values (no requirement on the order of the returned values, this
would be the job of the disambuating method).
And the way I understand it, the algorithm for disambiguating candidate
methods is
1- call a method that will apply an algorithm only based on deterministic
relations between known-to-the-implementer-or-user existing methods.
Why not make this 1- behavior just a "default" behaviour, and let the
possibility for the user to totally use another one, by passing it to the
defmulti declaration as a function :
(fn [computed-value candidate-values])
(I'm not sure computed-value is interesting here, though, but maybe better
have it than not)
This method could return an ordered list of candidates.
a) if the list is empty, then prefer-method will be called in a last resort
b) else the first item of the list is the method to dispatch to. And the
rest of the list could be passed to the method in a non intrusive way (could
it be via rebinding a global ?)
Thanks if you read past through this :-) And I'll be happy to see comments
on this one. This really reflects what I had in mind for some time, so if
I'm wrong in certain (or totally) areas, I'll be happy to learn from my own
errors :-)
--
Laurent
>
>
> Konrad.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
