dispatch, so I wanted to add some points to the discussion.
The design of Mathematica's pattern matching is tightly coupled to the
language's computational model, as well as with all other aspects of
the system. So a lot of it would get lost in translation to Clojure,
and not give you as much mileage as it does in Mathematica. So I'm
mostly gonna focus on some pitfalls rather than the upside.
The biggest problem for the developer is understanding the state of
the rules system, especially during interactive development.
Mathematica tries it's best to insert new function definitions in the
"right" order, trying to figure out if pattern X if a subcase of
pattern Y, etc. Of course, there are ambiguous cases, particular since
the pattern language is rich. You solve this problem by either making
your pattern more specific, changing the order in which definitions
are loaded, or attaching the definition another symbol that has higher
So debugging the pattern ordering is something you end up needing to
know how to do.
But this exposes a bigger problem: when doing interactive development,
you will end up with old definitions sticking around. You are
debugging one case of your function, and change the pattern a little.
The old pattern is still there, potentially shadowing the new one. So
anytime you see unexpected output while debugging, you need to wonder
about the state of the definitions and if you should reinitialize
You can also get a function that works at the repl, but its broken in
source. The way this happens is, you enter definitions in arbitrary
order at the repl, but they are in a different order in source. So in
cases where order matters, this can get you too.
I've pretty much had every possible situation happen.
In Mathematica, it's possible to manually specific the order of the
definitions, but it's too cumbersome to use in source code.
In Clojure, the situation is simpler, and that helps. The pattern
language (or versions that we've seen of it) is simpler, and
destructuring is not part of its mission. (Changes to destructuring
are a common source of this shadowing issue.) There is also the
core.logic engine to do more deduction about the patterns themselves.
Still, I still see the two problems of 1. debugging the ordering, and
then 2. dealing with the state of the definitions during debugging and
On 1, the best thing is if you look at the source and immediately
understand what the ordering will be. So when you are writing code,
you just have this simple mental model, and spotting mistakes is easy.
For example, if the system does no "intelligent" ordering for you, its
obvious what the order at runtime will be, and you don't have to fight
anything to get things into the desired order.
On 2, this is more tooling support, in rough order of importance
-- which case is called for input X, and why
-- debugging a specific case independent of all others (suppress the
-- various operations for comparing and testing patterns
-- ide support for displaying / editing the ordering of definitions
I've spent a ton of time debugging this stuff; its really important to
have a quick way to find out why something happened in these open
matching systems, and then have a convient way to patch the behavior.
Its just not as easy as changing a cond case in a single place in
The great thing about pattern matching in Mathematica is that it is so
deeply integrated with all kinds of other primitives, from string
manipulation, data manipulation, math stuff, the equivalent of Map,
the equivalent of macros. So my question is can clojure-style pattern
matching and predicate dispatch be equally as powerful and pervasive,
but it it's own way.
One thought I had is about the relationship with program querying.
With predicate dispatch, you'll have greater runtime control over your
program, can swap things in and out at a finer granularity. And with
this idea of program querying that Rich talked about, you might find
all sorts of behaviors in your program that you might want to do
something about. Seems sort of complementary.
Maybe there is something there at that intersection, that can be a
greater extension of logic-based programming beyond only extending the
multimethod concept. So instead of replacing defn or defmulti, there
could be an entirely different use case, and it would be obvious which
one to use when.
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to firstname.lastname@example.org
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
For more options, visit this group at