Comments on: Multimethod in Clojure: Should I call it first class Pattern Matching? or Pattern Matching in disguise?

By: Werner Schuster (murphee)

Werner Schuster (murphee) — Fri, 29 May 2009 09:39:38 +0000

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).

By: spooky

spooky — Thu, 28 May 2009 23:00:39 +0000

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

By: Sadache

Sadache — Thu, 28 May 2009 10:56:37 +0000

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.

By: Rich Hickey

Rich Hickey — Wed, 27 May 2009 21:59:46 +0000

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.