On Mar 31, 11:45 am, Konrad Hinsen <konrad.hin...@laposte.net> wrote:
> On Mar 31, 2009, at 16:32, Rich Hickey wrote:
>
> > Here are some problems/limitations of existing OO/GF systems that I
> > don't intend to repeat:
>
> ...
>
> I agree that these are not desirable features. I have had to work
> around some of them many times in the past. Traditional OO combines
> aspects that should better be handled separately.
>
> > Here are the areas I'm looking to improve:
>
> > - There's no easy way to talk about "the method you would get if you
> > were dispatch value X". Note that this is not the same as call-next-
> > method, which reintroduces global ordering requirements, but allows
> > for easy explicit reuse of already-defined methods.
>
> That would be VERY nice to have. More than once I ended up writing a
> private function that I then called from several methods in the same
> multimethod, to avoid code duplication.
>
> > - Currently, a preference doesn't encompass the path through the
> > preferred value to its ancestors, but could.
>
> > - If you have a set of common preferences, there's no easy way to
> > create them in advance and share them among methods. There are issues
> > here related to ensuring preference consistency and caching.
>
> At the moment, a multimethod takes two dispatch-oriented parameters:
> a hierarchy and a dispatch function that returns a single item from
> the hierarchy.
>
> How about generalizing the dispatch function in two ways:
> - it can return a sequence of items that will be tried in order
> - it can access the hierarchy
>
> Accessing the hierarchy is a minor point since this is already
> possible (write a dispatch function that uses parents, ancestors,
> etc.; for a hierarchy other than the global one, make the dispatch
> function a closure that refers to the hierarchy). Maybe it could be
> made more convenient.
>
> Returning a sequence should be sufficient to let the dispatch
> function handle any kind of preference. prefer-method could thus go
> away. Instead, there would be a set of utility functions to
> facilitate writing dispatch functions for common cases. A single
> dispatch function could be used for any number of multimethods.
>
> I think this should be sufficient to cover all cases you mentioned,
> but of course it needs to be tried in practice.
I think the orthogonal elements of multifunction dispatch are type
computations, traversals, and matchers (and the functions being
dispatched to, of course).
"Dispatch function" is maybe an unfortunate name; those functions
aren't dispatchers, they're type-returning functions--functions that
compute selector values.
If you have a way to compute selector values from inputs and a way to
specify the order in which matches against them will be tried, and a
way to specify how matching is to be performed, then you have the
tools to specify any dispatching algorithm you like. Clojure presently
provides some tools for this: "dispatch functions" are type-returning
functions; hierarchies are graphs of selector values; isa? and prefer-
method are a control language for describing traversal, and isa? is
also a matching function.
But these are restricted versions: dispatch functions are meant to
return a restricted range of values--symbols, keywords, classes, and
certain collections of those values; multifunction dispatch supports
hierarchies, but not other kinds of graphs; isa? and prefer-method are
the only vocabulary we have for describing traversal, and isa? is the
only matcher (almost the first thing I wanted to do when using
MultiFns was replace isa? with my own matching function).
The tools can be more expressive. Multifunction dispatch can be built
on user-specified traversals of user-designed graphs of selector
values, computed by user-supplied type-returning functions, and using
user-specified matchers. The traversal order, the range of selector
values, the language for describing traversal, and the matching
procedure can all be more first-class and more orthogonal. Special
cases can be provided for specific combinations known to be especially
useful or efficient.
With a full set of tools for describing dispatch, any differences of
individual taste in function dispatching and type relationships
becomes moot, because the tools are there to implement whatever type
relationships and dispatching algorithm you want. Rich doesn't want to
enshrine a particular traversal order in Clojure; I want the power to
comprehensively specify traversal order in advance for certain uses;
very well, any traversal order (or no traversal order) may be defined,
as you like. He wants function dispatching and data definitions to be
separated and so do I; very well, we have the freedom to compute
whatever values we wish for use as types, and to arrange them in
whatever sorts of graphs we like. Everyone wants things to be
efficient, and likely people also want common use cases to be provided
ready-to-wear; very well, those cases can be provided as built-ins or
elements of libraries, with special treatment in the compiler where
it's warranted for important cases, and without compromising the
expressiveness of the basic mechanisms.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
