On Mar 31, 2:18 pm, mikel <mev...@mac.com> wrote:
> 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).
>
What about predicate, or rule based dispatch - why hardwire the notion
of types, traversal or matching?
> "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.
This is simply an exhausting amount of talk - how about a prototype?
I'm skeptical there will be much utility left in the harness that
hosted all of these plugin components. With no knowledge of how the
pieces fit, it couldn't even do the most basic cache management or
consistency checking jobs.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
