Neither of these work as expected:

(match [ {:type :consumed :value 4}]
[({:uid uid :modifiers ms} :only [:uid :modifiers])] :a0)

(match [ {:type :consumed :value 4}]
[{:uid uid :modifiers ms} ] :a0)

Tried these versions:
"0.2.0-alpha10-SNAPSHOT"
"0.2.0-alpha9"

Nested rest patterns combined w/ vector patterns cause an infinite loop.

Right now they fail since heterogenous keys can't be sorted.

AFAIK we need to migrate to Maven for Contrib projects.

I used core.logic as a template and it seems to have been successful. Anything missing?

https://github.com/clojure/core.match/commit/5146212edecbd8d765028e165352d20005b44cc3

The issue is the same as stated on
https://github.com/swannodette/match/issues/54
but moved here as a part of moving match to Clojure contrib.

Here is a copy of the text from the issue above:

After having forked the latest version on branch and compiling I attempted to execute the infamous red-black tree rebalancing code.

(let [node nil]
(match/match
[node]
[([:black [:red [:red a x b] y c] z d] |
[:black [:red a x [:red b y c]] z d] |
[:black a x [:red [:red b y c] z d]] |
[:black a x [:red b y [:red c z d]]])]
[:red [:black a x b] y [:black c z d]]))
The good news is that issue issue 47 is indeed resolved. The bad news is that a new issue has cropped up, namely that the ClassFormatError with the message

error: java.lang.ClassFormatError: Invalid method Code length 78596 in class file redblack/core$eval3306 (core.clj:10)
is raised.

The red black tree balance pattern mentioned by tgk generates enough code that the JVM will not inline it. Maranget's algorithm basically implements backtracking by passing along wildcard matches with actual matches. For non-overlapping patterns like the red black tree balance pattern this means exponential code size.

For such patterns where none of the actions involve recur we could implement backtracking with a pre-allocated exception.

http://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive

(let [v [[1 2]]]
(match [v]
[[3 1]] :a0
[[([1 a] :as b)]] [:a1 a b]))

Throws out of bounds exception error

The binding in the match macro used in gitolite-webui.notification 41:

(defn email-request [req]
(match [req]
[{:name _ :repo (r :when (comp not nil?)) :email email}] (notify-user-constrained email "Your repository access request has been approved" (<< "Verify that you can access it by cloning ~(:repo req) repository.") @config)
[{:name _ :key _ :email email}] (notify-user-constrained email "Your key request in gitolite was approved" (<< "Please verify that your public key matches ~(:key req)") @config)
))

Trying to create jar results with:

(match-fix)⚡ % lein uberjar ~/CodeProjects/gitolite-webui
Cleaning up.
WARNING: gitolite-webui.notification, line 42: Non-exhaustive pattern matrix, consider adding :else clause
Exception in thread "main" java.lang.Exception: Unable to resolve symbol: email in this context (notification.clj:43)
at clojure.lang.Compiler.analyze(Compiler.java:5205)
at clojure.lang.Compiler.analyze(Compiler.java:5151)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5371)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyze(Compiler.java:5151)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2315)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5369)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5357)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5357)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyze(Compiler.java:5151)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5357)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyze(Compiler.java:5151)
at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:798)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5369)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5357)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.access$100(Compiler.java:35)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:438)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5369)
at clojure.lang.Compiler.analyze(Compiler.java:5190)
at clojure.lang.Compiler.analyze(Compiler.java:5151)
at clojure.lang.Compiler.compile1(Compiler.java:5928)
at clojure.lang.Compiler.compile(Compiler.java:5992)
at clojure.lang.RT.compile(RT.java:368)
at clojure.lang.RT.load(RT.java:407)
at clojure.lang.RT.load(RT.java:381)
at clojure.core$load$fn__4519.invoke(core.clj:4915)
at clojure.core$load.doInvoke(core.clj:4914)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:4729)
at clojure.core$load_lib.doInvoke(core.clj:4766)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:542)
at clojure.core$load_libs.doInvoke(core.clj:4800)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:544)
at clojure.core$use.doInvoke(core.clj:4892)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at gitolite_webui.persistency$loading_4414auto_.invoke(persistency.clj:1)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2906)
at clojure.lang.Compiler.compile1(Compiler.java:5933)
at clojure.lang.Compiler.compile1(Compiler.java:5923)
at clojure.lang.Compiler.compile(Compiler.java:5992)
at clojure.lang.RT.compile(RT.java:368)
at clojure.lang.RT.load(RT.java:407)
at clojure.lang.RT.load(RT.java:381)
at clojure.core$load$fn__4519.invoke(core.clj:4915)
at clojure.core$load.doInvoke(core.clj:4914)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:4729)
at clojure.core$load_lib.doInvoke(core.clj:4766)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:542)
at clojure.core$load_libs.doInvoke(core.clj:4800)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:542)
at clojure.core$require.doInvoke(core.clj:4881)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at gitolite_webui.core$loading_4414auto_.invoke(core.clj:1)
at clojure.lang.AFn.applyToHelper(AFn.java:159)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2906)
at clojure.lang.Compiler.compile1(Compiler.java:5933)
at clojure.lang.Compiler.compile1(Compiler.java:5923)
at clojure.lang.Compiler.compile(Compiler.java:5992)
at clojure.lang.RT.compile(RT.java:368)
at clojure.lang.RT.load(RT.java:407)
at clojure.lang.RT.load(RT.java:381)
at clojure.core$load$fn__4519.invoke(core.clj:4915)
at clojure.core$load.doInvoke(core.clj:4914)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:4729)
at clojure.core$compile$fn__4524.invoke(core.clj:4926)
at clojure.core$compile.invoke(core.clj:4925)
at user$eval27.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:5424)
at clojure.lang.Compiler.eval(Compiler.java:5415)
at clojure.lang.Compiler.eval(Compiler.java:5391)
at clojure.core$eval.invoke(core.clj:2382)
at clojure.main$eval_opt.invoke(main.clj:235)
at clojure.main$initialize.invoke(main.clj:254)
at clojure.main$null_opt.invoke(main.clj:279)
at clojure.main$main.doInvoke(main.clj:354)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:369)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:482)
at clojure.main.main(main.java:37)
Caused by: java.lang.Exception: Unable to resolve symbol: email in this context
at clojure.lang.Compiler.resolveIn(Compiler.java:5677)
at clojure.lang.Compiler.resolve(Compiler.java:5621)
at clojure.lang.Compiler.analyzeSymbol(Compiler.java:5584)
at clojure.lang.Compiler.analyze(Compiler.java:5172)
... 100 more

Trying to use an else clause:

(defn email-request [req]
(match [req]
[{:name _ :repo (r :when (comp not nil?)) :email email}] (notify-user-constrained email "Your repository access request has been approved" (<< "Verify that you can access it by cloning ~(:repo req) repository.") @config)
[{:name _ :key _ :email email}] (notify-user-constrained email "Your key request in gitolite was approved" (<< "Please verify that your public key matches ~(:key req)") @config)
:else :error
))

Exception in thread "main" java.lang.RuntimeException: java.lang.IllegalArgumentException: No method in multimethod 'to-source' for dispatch value: class clojure.core.match.core.WildcardPattern (notification.clj:42)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:5376)

(match [[]]
[[]] "asdf")
#<RuntimeException java.lang.RuntimeException: java.lang.Exception: No match found. Followed 0 branches. Breadcrumbs: []>

Macro-expand'd:

(let*
[ocr-4856 []]
(clojure.core/cond
(clojure.core/and
(clojure.core/instance? clojure.lang.IPersistentVector ocr-4856)
(clojure.core/= (clojure.core/count ocr-4856) 1)) (clojure.core/let
[ocr-4856_0__4857
(clojure.core/nth
ocr-4856
0)]
(clojure.core/cond
(clojure.core/=
ocr-4856_0__4857
nil)
"asdf"
:else
(throw
(java.lang.Exception.
(clojure.core/str
"No match found. "
"Followed "
1
" branches."
" Breadcrumbs: "
'[(clojure.core/and
(clojure.core/instance?
clojure.lang.IPersistentVector
ocr-4856)
(clojure.core/=
(clojure.core/count
ocr-4856)
1))])))))
:else (throw
(java.lang.Exception.
(clojure.core/str
"No match found. "
"Followed "
0
" branches."
" Breadcrumbs: "
'[])))))

Clearly this test is the issue: (clojure.core/= (clojure.core/count ocr-4856) 1))

Sometimes pattern rows are not preserved in the user defind order. Fix this and create the tests to show that this property is preserved.

Following sample causes IndexOutOfBound exception.

(match [[:pow :x 2]]
[[:pow arg pow]] 0
[[:mult & args]] 1
:else 2)

Result: IndexOutOfBound

But if we delete '&' everything works fine:

(match [[:pow :x 2]]
[[:pow arg pow]] 0
[[:mult args]] 1
:else 2)

Result: 0

See: https://gist.github.com/1241625

Head-tail pattern matching only seems to work with vectors.

Commit: https://github.com/clojure/core.match/commit/9f4919d855be09a1b32f9e5563ac1c3f5bace642

The following code falls through. (macroexpand appended)

(let [x '(1 2 3)]
  (match [x]
         [[a & as]] :a))

(try
  (clojure.core/cond
    (clojure.core/instance? clojure.lang.IPersistentVector x) (try
                                                                (clojure.core/let 
                                                                  [x_left__3201
                                                                   (clojure.core/subvec
                                                                     x
                                                                     0
                                                                     1)]
                                                                  (clojure.core/cond
                                                                    (clojure.core/and
                                                                      (clojure.core/instance?
                                                                        clojure.lang.IPersistentVector
                                                                        x_left__3201)
                                                                      (clojure.core/=
                                                                        (clojure.core/count
                                                                          x_left__3201)
                                                                        1))
                                                                    (clojure.core/let 
                                                                      [a
                                                                       (clojure.core/nth
                                                                         x_left__3201
                                                                         0)
                                                                       as
                                                                       (clojure.core/subvec
                                                                         x
                                                                         1)]
                                                                      :a)
                                                                    :else
                                                                    (throw
                                                                      clojure.core.match.core/backtrack)))
                                                                (catch
                                                                  java.lang.Exception
                                                                  e__2436__auto__
                                                                  (throw
                                                                    clojure.core.match.core/backtrack)))
    :else (throw clojure.core.match.core/backtrack))
  (catch
    java.lang.Exception
    e__2437__auto__
    (throw clojure.core.match.core/backtrack)))

(match [false] [false] true) throws an error.

I thought I handled this case earlier, but seems like I missed something.

Following code:

(match [[:plus 1 2 3]]
[[:pow arg pow]] 0
[[:plus & args]] 1
:else 2)

Returns 2, but must return 1.

If we delete first clause it works:

(match [[:plus 1 2 3]]
[[:plus & args]] 1
:else 2)

Returns 1.

A post about matchure on the ML reminded about my original line of thinking. We should not use the backtracking solution if we detect the presence of recur in any of the action bodies. If it is present we should use the old compilation mechanism.

(let [x {:a 1 :b 2 :c 10 :d 30}]
(match [x]
[({:a _ :b _ :c _ :d _} :only [:a :b :c :d])] :a-1
[({:a _ :b 2} :only [:a :b])] :a0
[{:a 1 :c _}] :a1
[{:c 3 :d _ :e 4}] :a2
:else []))

returns :a1 instead of :a-1

(let [m {:a 1 :b 2}]
  (match [m]
    [({:a 1} :only [:a])] :a0
    :else :a1))

We get :a0 instead of :a1

(let [x '(1 2) y 1]
  (match [x y]
    [([1] :seq) _] :a0
    [_ 1] :a1
    [([1 2] :seq) _] :a2
    [_ 2] :a3
    :else :a4))

This returns :a2 when it should return :a1

user=> (match-1 :a :a (throw (Exception.)) :else :c)
:c

I would expect the exception to flow through the match. Instead, it gets eaten and one is left wondering why the proper clause "isn't matching".

Setting warn-on-reflection affects all use of core.match.

Please remove all cases where warn-on-reflection is set.

This can be set by the pom for the project, rather than in source, so it doesn't affect code using core.match.

matching literal vectors is not something we support so there can be no ambiguity.

Reported on the Clojure mailing list:

From: Alex Miller <alex@puredanger.com>
Subject: Symbol matching in core.match
Date: November 30, 2011 2:49:43 PM EST
To: Clojure <clojure@googlegroups.com>
Reply-To: clojure@googlegroups.com

I've been working with core.match some this week and finding it pretty
nice. However, I have a common case (for me) that is not well handled
right now via core.match: matching symbols. Say that I wrote a match
like this:

;; translate (+ x (+ y z)) to (+ x y z)
(let [e '(+ 1 (+ 2 3))]
(match [e]
[([+ x ([+ y z] :seq)] :seq)] (+ x y z)))

You will see this error:
Pattern row 1: Pattern row reuses wildcards in [([+ x ([+ y
z] :seq)] :seq)]. The following wildcards are ambiguous: +. There's
no guarantee that the matched values will be same. Rename the
occurrences uniquely.

Any symbol inside a pattern row is treated as a bind variable. + is a
symbol. You can achieve this with guards:

(defn +? [s] (= '+ s))

(let [e '(+ 1 (+ 2 3))]
(match ['(+ 1 (+ 2 3))]
[([(_o1 :when +?) x ([(_o2 :when +?) y z] :seq)] :seq)] (list
'+ x y z)))

but, yuck. I can imagine using the reserved ()'s with additional keys
(:symbol or :sym) to do symbol matching like (:symbol +) but also,
yuck. The simplest idea I came up with was:

(let [e '(+ 1 (+ 2 3))]
(match [e]
[(['+ x (['+ y z] :seq)] :seq)] ('+ x y z)))

These come through as (quote x) although the error reporting goes a
little off the rails:
Pattern row 1: Pattern row reuses wildcards in [([(quote +) x ([(quote
+) y z] :seq)] :seq)]. The following wildcards are ambiguous: quote.
There's no guarantee that the matched values will be same. Rename the
occurrences uniquely.

However, that seems fixable and you could then use (quote x) as a
signal to do symbol matching. If I can figure out what the hell I'm
doing in core.match then I'd be happy to work on a patch.

This expression fails to compile with a NullPointerException. Oddly enough I seem unable to make it any more minimal:

(match [["foo"]]
    [["foo"]] :a0
    [["foo" a]] :a1
    [["baz"]] :a2
    [["baz" a b]] :a3)

When I included the SNAPSHOT release in my project that seemed to fix it, but oddly enough I cloned the git repo this morning and it was still broken on HEAD, so I have no idea what's going on.

Macroexpanding an match expression with an :or pattern will show this.

Currently if patterns of the same type are not adjacent, matching fails unexpectedly. This should always work. This does beg the question about things which might possible match multiple clauses. When we get to predicate dispatch we may check for subsumption. However in some cases we might have something which is legitimately both things. We haven't decided yet how we'll handle that.

This is the simplest example I could come up with:

(defn f [xs]
(match xs
[:a] "a"
[:b b] b
[:c] "c"
:else "problem!"))

[:a] and [:b b] can be matched with no problems, but [:c] can't be matched for some reason:

user=> (f [:a])
"a"
user=> (f [:b 1])
1
user=> (f [:c])
"problem!"

The latter form is an implementation detail and doesn't work in the latest cljs compiler release.

The ClojureScript example in core.match's readme is failing at the moment, using core.match 0.2.0-alpha11:

(ns foo.bar
  (:use-macros [clojure.core.match.js :only [match]]))

(match [(mod 5 3) (mod 5 5)]
      [0 0] "FizzBuzz"
      [0 _] "Fizz"
      [_ 0] "Buzz"
      :else n)

ClojureScript:foo.bar> WARNING: Use of undeclared Var foo.bar/e__4345__auto__ at line 4 
clojure.lang.ExceptionInfo: Unsupported binding form: (if (clojure.core/identical? e__4345__auto__ 0) (do (clojure.core/let [ocr-5230 (mod 5 5) ocr-5229 (mod 5 3)] (try (clojure.core/cond (clojure.core/= ocr-5230 0) (clojure.core/let [G__5226 ocr-5229] "Buzz") :else (throw 0)) (catch e__4345__auto__ (if (clojure.core/identical? e__4345__auto__ 0) (do (clojure.core/let [G__5228 ocr-5230 G__5227 ocr-5229] n)) (throw e__4345__auto__)))))) (throw e__4345__auto__)) at line 4  {:tag :cljs/analysis-error, :file nil, :line 4}

The same error is produced with any usage of match in ClojureScript AFAICT, not just the README example. However, all is well with core.match AFAICT under Clojure, and if you use older revs of ClojureScript, e.g. r1552. I did a bisect, and found that this is the first ClojureScript commit with which the example does not work:

https://github.com/clojure/clojurescript/commit/88b36c1

Reverting it with master results in proper evaluation of the match, modulo the warning.

I don't see any obvious reason why the above would cause any problems, and some moderate digging based on what I know about ClojureScript didn't yield any ah-ha! moments.

=> (match 3 x x)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: ocr-34984 in this context, compiling:(NO_SOURCE_PATH:1:1) 
=> (macroexpand '(match 3 x x))
(let* [x ocr-35001] x)

(Discussed briefly here.)

I was looking at the code for clojure.core.match.bits, and there seems to be a reference to an example of parsing a dgram. The code looks to be broken or incomplete, or is it my understanding of it that is lacking?

If it isn't done, are there any plans to finish it up?

Rest patterns don't currently infer their type. A simple enhancement that would save some extra typing as well as potentially mysterious errors.

This is low priority, but should be investigated. To see this behavior just print out the pattern row at the leaf node cases. Encountered this while fixing symbol binding bug in vector patterns.

On the Clojure mailing list I wrote:

For guards, I wonder if the extra parens are really necessary. Couldn't the :when bind tightly to the previous pattern variable? Like Clojure FOR comprehensions. I think it would be easier to read that way. Same comment applies to :as. To cover the rare case of matching a literal :when or :as, you could quote it or use it as the first item in an OR pattern.

On Oct 10, 2011, at 3:11 PM, David Nolen wrote:

It would be nice to lose the extra parens - patch welcome

With the fix for MATCH-34, the function interpose1 is no longer used and can be removed. It was there only to support the old infix OR pattern.

I contributed the regroup-keywords function to allow 'flattened' match syntax for :when and :as. It used gensym to make a marker to simplify the algorithm. After seeing how other people had done similar things with sentinel values, I realized that (Object.) is a better unique value. Theoretically, an evil user could use the same symbol that the gensym had created. Also, it's better to test with identical? rather than = since the sentinel is unique. I will attach a patch with a slight refactoring.

The `.keySet` method call doesn't exist on JavaScript objects.
Master throws compile errors on me, so I've attached a patch against alpha9 that removes the Java method call in favor of the pure Clojure `(set (keys m))`

Anonymous function literals as guards (such as (a :when #(odd? %))) seem to confuse the match compiler. The attached test shows how.

Re: "As shown, :else clauses are special, in that they are not implicitely wrapped in []."

"implicitely" is misspelled, but "implicitly" would be the wrong word anyway as the intended meaning seems to be "explicitly". It would be clearer just to leave out the adverb.