from Rich Hickey on Clojure’s Features and Implementation
Clojure multimethods are just another level of that same logic, in fact they are a realization of the last sentence I just said. They are dispatch based upon an arbitrary function of the arguments. You define a multimethod and you say “Here is a function of the arguments I’d like you to use” You could look at the first argument, you could look at the 5th, you could look at all of them, you could look inside them, some member of an argument, it could look at the types or not or the values. Now, you could look at relationships between arguments, you have dispatch based upon an arbitrary function of the arguments and you have a vastly wider set of polymorphic possibilities than you had before and it’s quite powerful. In particular, it allows you to do Runtime dispatch on Runtime attributes. You don’t usually represent something like being hungry as part of something’s type, it’s some attribute that it acquires while the program is running or being outdated or things like that. Now you can access those things and you can do things polymorphically based upon that and take a lot of switch statements out of your code.
Should I call it first class Pattern Matching? or Pattern Matching in disguise?
Multimethods differ from pattern matching in a number of ways. Two that matter (to me) are:
Pattern matching is usually ‘closed’, in the sense that all possibilities must be enumerated in a single scope.
Pattern matches are usually declaration order dependent.
Multimethods, OTOH, are an open set. You can define a new method any time, anywhere – they need not be lexically co-located. Multimethod operation is independent of definition order. They are very dynamic, and thus a good fit for Clojure.
There are other differences, of course, e.g. pattern matching usually has sugar for structural and type matches, and often exhaustiveness checking. I’m still waiting for someone to contribute a pattern-matching macro for Clojure, as I don’t think one makes the other redundant.
Comment by Rich Hickey — May 27, 2009 @ 9:59 pm
Thank you Rich for the explanation. It reminds me now of a frequent question in the Haskell community about whether Type Classes overlap with GAT. It gets always back to the interesting property of open/close. I just can’t imagine enough the possibilities the mechanism offers in the same time as complexity it adds. I guess multimethod alone calls for a new paradigm of programming yet to be discovered.
Comment by Sadache — May 28, 2009 @ 10:56 am
Multimethods are normal in common lisp (CLOS) and several other multiple-dispatch languages. I have no idea how clojure’s might differ, but they’re not some new thing in the grand scheme of things.
http://en.wikipedia.org/wiki/Multiple_dispatch
Comment by spooky — May 28, 2009 @ 11:00 pm
Pattern Matching: My experience with pattern matching comes mostly from working with Mathematica, and I’m not sure I see the closed property there. You can define new ‘methods’ (in the multi-method sense) anywhere, anytime.
The evaluation order is based on definition order – BUT it can be changed by reordering the definitions (http://reference.wolfram.com/mathematica/ref/DownValues.html).
I have been thinking about doing Mathematica-style pattern matching with Clojure; I think it’s possible using the method reflection calls, which allow to get all the dispatch values + methods for a multi-method name. With that, it’d be possible to interpret the dispatch values as pattern definitions and to generate an optimized pattern matcher for a set of multi-methods. Mind you – I’m not sure how to get the openness property back, though. Ie. if a pattern matcher is generated for a set of multi-methods, and then someone adds another definition for a multi-method -> then the pattern matcher dispatch function would be outdated. The only solution would be to have a dispatch function that always gets the definitions of all the multi-methods, and does the pattern matching with that – but that’d preclude the construction of an optimized, specialized pattern matcher function.
As for where multi-dispatch fits – as I argue here:
http://www.jroller.com/murphee/entry/hell_hath_no_fury_like
it’s a very general type of (runtime) polymorphism – so general that it subsumes many specialized features of OOP languages (static overloading, virtual methods, etc As we see with Clojure’s dispatch functions, they can also be made to implement class hierarchies).
Comment by Werner Schuster (murphee) — May 29, 2009 @ 9:39 am