On Mar 25, 6:47 am, mikel <mev...@mac.com> wrote:
> On Mar 25, 4:13 am, Mark Engelberg <mark.engelb...@gmail.com> wrote:
>
> > On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen
>
> > <konrad.hin...@laposte.net> wrote:
> > > Could you elaborate a bit on this? I haven't met any major obstacles
> > > with multimethods yet. The dispatch functions give quite a lot of
> > > flexibility in practice. In what situation did you find them
> > > inconvenient?
>
> [... good points snipped...]
>
> I agree with all the points you raise here.
>
> > 3. The dispatch mechanism requires a lot of explicit prefer-methods,
> > or else it may be hard to guarantee you won't get a run-time error
> > from a situation the dispatch system considers ambiguous. This also
> > makes code less extensible because to add a method, you must know
> > about all the other methods that have been implemented in order to
> > insert all the appropriate preferences.
>
> [...]
>
> > it seems like Clojure's multimethods are less
> > sophisticated than their CLOS/Dylan counterparts
>
> I dunno if I'd go that far. What I can say is that you don't need
> anything like prefer-method to prevent dispatching ambiguities in
> either CLOS or Dylan. The requirement to hand-tweak dispatching
> strikes me as particularly ugly. How can I design an extensible API on
> MutiFns? I have no idea. Defining a new method can introduce an
> ambiguity in dispatching that requires a prefer-method call to fix.
> When I'm implementing the library, that's just a minor annoyance, but
> when I contemplate delivering it to someone else for use and
> extension, it suddenly turns into a major headache. Users of that
> library can break existing code by defining new methods, because new
> methods may introduce dispatching ambiguities. In order to fix the
> breakage, they need to know the right prefer-method calls to make.
> That means they need to understand esoteric details of the library
> implementation for no good reason--for no reason at all, except that
> if they don't know them, they won't be able to make the right prefer-
> method calls.
>
> Yuck.
I wonder about the generality of this concern. Defining new methods
that break existing code implies both defining new methods on existing
super-types *and* some crosscutting multiple inheritance. I've seen it
happen only when first building method sets on existing hierarchies
not designed with this system in mind, e.g. when superimposing methods
on Java hierarchies. If you have an existing hierarchy from CLOS and
are disappointed that Clojure's multimethods don't work like CLOS,
well, ok.
However, all is not rosy with CLOS, and I've run into problems with
the left-to-right semantics of both arglists and superclass lists many
times, trying to game precedence lists etc. There's somethjing
inherently broken with not being able to derive from two superclasses
that have the same bases, just because they have different derivation
orders - see bottom of:
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_4-3-5-2.html
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 reason Clojure doesn't have an elaborate system like CLOS, or even
like Python et al is that all of those systems have limits and quirks
and hardwiring one into a language is a bad idea, IMO. Clojure's
hierarchies and multimethods are just libraries - there's no reason
you couldn't define a CLOS-like object system for Clojure (although
any such system will have problems integrating Java's type hierarchy
because there is no definitive superclass ordering). I'm just trying
to tease out the useful ingredients of OO and make them available a la
carte.
Two things contribute to the sometimes-convenient default resolution
policy of CLOS:
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). The other is default precedence of
classes based upon left-to-right declaration in defclass, and
topological sort based thereupon.
Right now, both matching and precedence follow isa?, but the latter
need not, or could be supplemented. Here are the characteristics I
think are important:
- It should be possible to superimpose a parent on an existing child
without modifying the child. This is a critical feature of Clojure's a
la carte hierarchies and one which I have desired in every OO language
(including CLOS) I have ever worked in. Requiring a client of
(independently developed) A and B to have to modify A in order to have
it work with B is unworkable.
- It should work transparently with Java hierarchies, which also
implies the above.
- It should support independent and order-independent assertions about
the hierarchy. Anything based upon canonic master definitions is
brittle and inextensible.
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.
That said, perhaps the preference specifications at the method level
aren't as reusable/convenient as preferences declared at another level
or somewhere else.
I do care about making this easier to use, but arguments from
familiarity are insufficient - we have to acknowledge the tradeoffs
involved. I am not willing to repeat this behavior of CLOS for the
sake of convenience:
(defclass a () ())
(defclass b () ())
(defclass c (a b) ())
(defclass d (b a) ())
defclass e (c d) ())
(make-instance 'e)
Error: Error during finalization of class #<STANDARD-CLASS E
216B409B>: Cannot compute class precedence list for class: #<STANDARD-
CLASS E 216B409B>
Yuck.
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
-~----------~----~----~----~------~----~------~--~---
