I tried to use :when to detect when key is not found. But this doesn't work either.
(match {:foo 3}
{:uid (uid :when #(not (nil? %)))} :a0)

Looks good, but can you create the patch so that it contains your credentials as well as test cases? Thanks!

added unit tests and attribution info.

I've manually applied this patch to the latest master and verified that it fixes the issue.
Patch attached and also available on the Github:

https://github.com/lynaghk/core.match/tree/issue-52

EDIT: spoke too soon; I can't seem to upload the patch to JIRA as a commenter. Available here: https://github.com/lynaghk/core.match/compare/issue-52.patch

I've also added a commit on top to get ClojureScript support.
The implementation feels a bit gross to me (it inlines the clojure core.match val-at* function, basically) but a nicer solution isn't obvious to me given ClojureScript's macro/runtime divide.

Updated Jason Jackson's patch with CLJS support.

Fixed, http://github.com/clojure/core.match/commit/7f73cee3f78417f1fb59bcbb4a8cda52de22efbd

See MATCH-17 and MATCH-14

Fixed, https://github.com/clojure/core.match/commit/3a2e5598b6fc7ad52caa0869802d0ed80ba54124

This looks OK to me, do all tests pass?

Yep, all tests pass.

lein --version
Leiningen 1.4.2 on Java 1.6.0_26 Java HotSpot(TM) 64-Bit Server VM
The project.clj file is as follows:
(defproject redblack "1.0.0-SNAPSHOT"
:description "FIXME: write"
:dependencies [[org.clojure/clojure "1.2.0"]
[org.clojure/clojure-contrib "1.2.0"]
[org.clojure/core.match "0.2.0-SNAPSHOT"]]
:dev-dependencies [[swank-clojure "1.3.0-SNAPSHOT"]])
core.match is compiled and installed using the above environment by issuing mvn install

Do you encounter this error at the REPL?

Sort of - it is encountered when connecting to the REPL using swank form emacs.

Can you elaborate the exact steps? What OS?

I'm interested in knowing the details since I haven't run into it myself - solving http://dev.clojure.org/jira/browse/MATCH-1 should address this problem.

I have executed all my tests on a mac os x lion 10.7.1. I've just added my (failing) code to github, it can be found here:
https://github.com/tgk/RedBlackTreesUsingMatch

The steps are as follows:
lein deps
lein swank
From aquaemacs, connect to swank using slime-connect
Open the file src/redblack/core.clj
Execute the entire file (C-c C-k if memory serves)

Sorry for the very brief description, but I'm at work...

Here's a bit longer description:

First, I cloned clojure.core.match.core and installed it using
mvn install

I have added a :main description to the project above. To make it fail I can simply use
lein run

I have also tried using 1.3.0-master-SNAPSHOT of clojure but with no luck. Which version of java are you using?

I have also tried using 1.3.0-master-SNAPSHOT of clojure but with no luck. Which version of java are you using?

Sorry been a bit swamped so I haven't had a chance to go through your exact steps (I'm sure I'll get the same error). Again I'm pretty confident I know why the red black tree pattern generates so much code. Adding backtracking will be a significant code size optimization.

See MATCH-1

Fixed now in master.

Fixed now in master.

Fixed, https://github.com/clojure/core.match/commit/2f5d82bfb6031325114b9a5aaad975fb60dd7bd3

Latest HEAD version of match while compile my project https://github.com/narkisr/gitolite-webui/tree/match-fix

Thanks! However, this is too much context. Please add an isolated case. This limits the moving parts as well as make it easy to add a new test case to handle your issue.

Hey David, iv created a single file project that reproduces this:

https://github.com/narkisr/MATCH_15

The single function in there is:

(defn email-request [req]
(match [req]
[{:name _ :repo (r :when (comp not nil?)) :email email}] (println email)
[{:name _ :key _ :email email}] (println email)
))

Running lein uberjar results with the same error.

Turns out this only affected AOT code. We were doing some dynamic things that did not play well w/ AOT. Fixed in master, https://github.com/clojure/core.match/commit/64eb9d4ff8774c3f228cfa8958043a65c083ec86

Bah, I'll try again:

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

(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: "
                '[])))))

Fixed, https://github.com/clojure/core.match/commit/9ba924ddd4e8cf9f08d44f2362bf04add1b69ae1

Fixed, https://github.com/clojure/core.match/commit/5e2762fbca6179b3b19505d7603fc6a37108dba1

No tests. The rule is never reorder - always return 1.

Fixed, https://github.com/clojure/core.match/commit/e0677eec1dac387e369886a72c19f75262cecd68

Fixed, https://github.com/clojure/core.match/commit/1b01e7fc6634e081f6a96db41eb65c91b95b8161

This is the expected behavior. If you want to match seqs you have to use the seq pattern syntax.

Fixed, https://github.com/clojure/core.match/commit/66a36260eb77c1920f9db011cdb612d4797665a7

Also works with [:plus 1 2] - vector size is now 3, was 4:

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

I have a pretty good idea what's wrong here as well as the fix. Hope to get this resolved in the next couple of days.

Fixed, https://github.com/clojure/core.match/commit/02f2ab62cba3d1017c2590b04946cb2c92190635

Fixed, https://github.com/clojure/core.match/commit/af4ca0425daee7dd7421716f6a151d2dda988a9a

Fixed, https://github.com/clojure/core.match/commit/61e05362872d7f336e0c12c42765806a9e5b8fc4

Fixed, https://github.com/clojure/core.match/commit/3407090009b447b594a7c361c8891f9b6e8f72bb

Fixed, https://github.com/clojure/core.match/commit/efa880320fc235536690ba8af078a59c17f3321d

match 0.2.0-alpha4, clojure 1.2.0

Fixed, https://github.com/clojure/core.match/commit/94f240dee09434ab87d2f901c647fdbd73792e89

Fixed, https://github.com/clojure/core.match/commit/f75152edb697cff9bbe9070478b5bc0105f140ca

Do you have an example of setting it in the POM?

Thanks!

I assume the clojure build is using clojure-maven-plugin, in which case it is just a matter of setting warnOnReflection. Something like this (untested):

<build>
 <plugins>
  <plugin>
    <groupId>com.theoryinpractise</groupId>
    <artifactId>clojure-maven-plugin</artifactId>
    <configuration>
      <warnOnReflection>true</warnOnReflection>
    </configuration>
  </plugin>
 </plugins>
</build>

Fixed, https://github.com/clojure/core.match/commit/af647a77415f5a8c8cc3d1222873b55f91241dde

Fixed, https://github.com/clojure/core.match/commit/c9e47acfc7dd4364428cfe011476a3492787f050

Checks for duplicate wildcard names in a pattern row.

You should be able to reuse bindings as is done in the red black tree pattern as there is no ambiguity there. If we can get that enhancement in I'll gladly accept this. Thanks for taking this on!

The new patch allows OR patterns to reuse wildcards, but still complains if there are other ambiguities. I added a couple of tests to illustrate.

This looks good. It looks like you created this patch before I added your match-let. Mind creating a new version of this patch against HEAD? Thanks much.

Updated patch for latest HEAD

I'm trying to apply with patch with git am, but I keep getting:

Applying: * src/main/clojure/clojure/core/match.clj: Add Stephen Miner's match-let
error: patch failed: src/main/clojure/clojure/core/match.clj:1532
error: src/main/clojure/clojure/core/match.clj: patch does not apply
Patch failed at 0001 * src/main/clojure/clojure/core/match.clj: Add Stephen Miner's match-let

It looks like the previous commit of my pasting of your match-let patch is mixed up into your latest patch.

Sorry, I made a git mistake with dup3.patch. I made a fresh patch called dup4.patch that should fix the problem.

Fixed https://github.com/clojure/core.match/commit/819f7f7d874f63b74ba634a9bebc95da574d80eb

Fixed, https://github.com/clojure/core.match/commit/0195f7211d44e15d40a35445b4882fcaf5bc9fb6

Fixed, https://github.com/clojure/core.match/commit/5edc28c6cd5315818ec2a852e931f5b7fe7dff35

Skip anything that's quoted when looking for duplicate symbol names. Added a test for the reported case.

patch attached

Fixed, https://github.com/clojure/core.match/commit/6721be4fba74561038539e12667bc04cc5fc94cc

Ubuntu 10.10

java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.10) (6b20-1.9.10-0ubuntu1~10.10.2)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)

Fixed, https://github.com/clojure/core.match/commit/a790f7900da9152dcdf290ade34b8001c47869f1

Fixed, https://github.com/clojure/core.match/commit/c1430c98937f31a0c8d2a92d793b0795b2c9a1d6

Fixed, https://github.com/clojure/core.match/commit/29607a2105d8af90c5b8d9d4cde9191e63a2570c

Clojure 1.3, core.match 0.2.0-alpha8

This will have to wait for http://dev.clojure.org/jira/browse/MATCH-31. There are some deeper issues with vector pattern matching that need to get ironed out first.

In the meantime just put your [:c] test above [:b b]. The key idea is to keep vector patterns of the same size "together".

fixed, https://github.com/clojure/core.match/commit/b2ee29d701a9306c1c494d91c371c01a512aee0c

Patch against master to use cljs.core/ILookup. Also available at https://github.com/lynaghk/core.match/tree/62-cljs-protocol

fixed, http://github.com/clojure/core.match/commit/241a3a3ab5344cc7c97fb3ab0b3783ce97b09f6d

Fixed, https://github.com/clojure/core.match/commit/ac92c6df3f70f56fbe12f9d3f46585e66102c50b

fixed http://github.com/clojure/core.match/commit/3bab92b6620dccdcb9e55941af4599e3adf78a6e

Thanks for looking at this!

fixed, http://github.com/clojure/core.match/commit/02a833efb959e0518f264ded3b98ce4215b5622c

The bits and array namespaces are experimental I've left a comment in both namespaces that states that.

http://github.com/clojure/core.match/commit/511b786b9545f5c00a629fa27be0ee2a6b01e2ae

Fixed, https://github.com/clojure/core.match/commit/d8e767948977837bfb138b9383d6f7c2d175c09e

Fixed, https://github.com/clojure/core.match/commit/7ceffec3876b5175f33182e75c91e2c8046a19e4

I attached a patch that groups the :when and :as terms appropriately given a "flattened" syntax. That is, [a :when even?] becomes [(a :when even?)] before being processed as usual. I only applied it to the top-level of the pattern row because I was concerned about recursive performance and things can get pretty complicated so maybe the magic isn't worth it.

Only :when and :as at the top level get any special treatment. No mangling for :seq or ::vector, etc. No mangling of nested patterns.

I also added a couple of tests for my changes.

I wrote an improved patch that should handle nested patterns as well. Still only groups :when and :as, not :seq since that seems sort of special.

Better to use seq? instead of list?

At first glance this looks pretty neat! Will try to take a deeper look today. Thanks!

One issue I have with this syntax enhancement - how does one match :when or :as as literals?

The patch tries to group the :when or :as if that makes sense. If it doesn't make sense [:when true nil], it leaves it alone so that would match the literal. In the rare case where it would be ambiguous, you would have to use a single OR pattern to get a literal match, such as [a (:when |) false]. I put something like that in one of my new tests.

By the way, it might be nice to allow a single element list to match that single pattern. That is, treat [(p)] the same as [p]. Right now, it's considered an error. It would also simply my patch, where I had to introduce interpose1 (as a variant of interpose) to handle an edge case with the OR pattern.

I'm not a fan of (:when |). I'd prefer it if the patch included support for always matching literal keywords that are written as ':foo.

Revised patch to support ':when (and quoted keywords in general) to match the literal keyword. Updated against HEAD.

Fixed, https://github.com/clojure/core.match/commit/d69abfaf68a86d5b9d73070e666720770779118f

Fixed, https://github.com/clojure/core.match/commit/314c665197bf6f74ed5e66518e93b48f5778ff60

Fixed, https://github.com/clojure/core.match/commit/6d0f3fe33c4a85a12366d447e82cab59e299f94a

It would preferable to check the *clojurescript* dynamic var and do different emission. Thanks!

Updated patch against master that uses clojurescript var. Also available at https://github.com/lynaghk/core.match/tree/60-cljs-keyset

fixed, http://github.com/clojure/core.match/commit/cdeea55f211f1dbe4768c8aec3149bfcb00438a2

I'm on the fence about allowing inline fn expressions and fn literals as guards. The problem is that they can't be checked for equality and thus tests cannot be shared across guard patterns. I need to think about it some more but I don't consider this high priority in the near future. Any decision will have to take into consideration the goal of predicate dispatch.

Sorry, I think the fact that the functions in my earlier example were function literals was a bit of a red herring. The following test also fails.

(deftest guard-pattern-match-5
  (is (=
       (let [oddp odd?]
         (match [1 2]
                [a :when odd? b :when odd?] :a1
                [a :when oddp _] :a2
                [_ b :when even?] :a3
                :else :a4))
       :a2)))

The earlier examples where not a red herring. This is likely a separate issue.

I really don't see how, given that there seems to be no code that specializes on the type of function given to a guard. My guess is that when guard-pattern-match-5 succeeds, guard-pattern-match-4 will succeed as well.

Oh sorry you are right. This is exactly same problem. We can't know that odd? and oddp are the same. Again this is not something I'm interested in fixing without a lot more consideration.

Basically functions can't be tested for equality like types can. This means that the presence of a guard must create a backtrack point. However if we make guards work a little more like types (you have to declare them ahead of time) we lose a little bit of convenience but gain a lot of reasoning power and can share tests and avoid these pitfalls.

This discussion probably needs a design page.

Two more examples of the same problem, this time not using guards:

(deftest unequal-equal-tests
  (is (=
       (match ["foo" "bar"]
              [#".*" #"baz"] :a1
              [#"foo" _] :a2
              [_ "bar"] :a3
              :else :a4)
       :a2)))

(deftest unequal-equal-tests-2
  (is (=
       (let [a 1]
        (match [1 2]
               [(:or 1 2) 3] :a1
               [(:or 2 a) 2] :a2
               [1 _] :a3
               :else :a4))
       :a2)))

They are not the same problem. These don't work for very different reasons. The first I probably won't even address and will leave for the community to deal with - I don't need robust pattern matching on regexes.

The second example is a legitimate bug around matching locals which is unrelated to this ticket. Feel free to open a new one for it.

Yes, you're right, the second is unrelated.

On further reflection, what all these examples show is that Maranget's algorithm is only correct for literals whose equality you can test at compile time. Thus, not even locals will work using his algorithm. Regexes and functions will certainly not work correctly 100% of the time.

What happens is that when multiple unequal tests in the same column can return a truthy value, you end up with a decision forest rather than a decision tree. If the first decision tree in the forest has the first and third end-states, while the second tree has the second end-state, if you end up in the third end-state, you must still check the second decision tree before you decide which end-state is actually correct.

This is a shame, since it means that compiling the matches becomes more complex. On the other hand, it seems like a great subject for a paper at programming-language conference, so there's always that.

On a serious note, though, this bug is major, and you should consider removing support for at least guards, locals, and regexes until it is fixed. The bugs that arise from it in the end-user's code are really hard to track down – it's as if `or` or `and` were broken 10% of the time.

There is nothing wrong with Maranget's algorithm. We just have to be sure that we create a backtrack point - that's all.

Functions cannot be fixed because function equality is undecideable. So for guards we might create a backtrack point. I've already updated the README to describe what works at the moment. I have a branch which throws an error if :when is not given a vector of symbols or a symbol. It should probably be improved so that symbols are known top levels (no reassigning fns to locals).

Regex equality can probably be made to work but I'm not going to do it. (On further thought we can probably make patterns create backtrack points by default, can be overridden for those willing to make their patterns highly optimizeable)

Locals can be fixed, we'll definitely create a backtrack point for these.

I'm sorry, but this problem will not be solved by backtracking alone. At least not with the backtracking mechanism that currently exists.

With backtracking, you are still treating the problem as though you have a decision tree. A decision tree requires that all the tests at its nodes are mutually exclusive.

By assuming that you have a decision tree, once a match is found in the tree, that match is returned. As my last comment pointed out, that is not sufficient. You must also check to see if there is a match in an end-state that was declared earlier. I really don't see that that's possible given the current backtracking system.

I don't follow you. Maranget's algorithm is not sufficient for pattern matching if we don't constrain columns to specific types. There are many things already in place to deal with the shortcomings of Maranget's approach given what we want to accomplish - for example, we actually have a grouping pass. This is the same approach that Racket uses as far as I can tell and they don't have any problems. Certainly none of the patterns you shown thus that far (besides fns exprs) pose any challenges that I can see.

Sorry, I was editing my comment as you made yours. I hope it is more clear now.

I guess I don't totally understand your code still, so I will try to rectify that before commenting again. From what I have seen, though, you are trying to build a decision tree. What I am saying is that isn't possible at compile time, since you can't ensure that the nodes of the tree are mutually exclusive.

All known constructors are considered mutually exclusive. We group all constructors in a column preserving order as closely as possible. Decisions trees are created for these constructors. If we cannot know at compile time whether something is mutually exclusive (wildcards, locals), we create a backtrack point to handle them.

Consider that if we only have backtrack points (no trees) all tests could potentially be tried. Our approach is a hybrid one - we don't rely only on decisions trees and we don't rely only on backtracking.

When we get to integrating pattern matching on interfaces, protocols ambiguities of course become possibly. But even this can probably be handled reasonably with something like "prefers".

Consider the following pair of decision trees:

  1
 /
a
 \
  3*

  2*
 /
b--4*
 \
  5*

Where the numbers are the order in which the terminals appear, and they have stars beside them if they match. The correct terminal for core.match to return in this case is the second one. Currently, the code would return the third terminal. Suppose, however, that backtracking was added so that the tree rooted at b was checked for matches as well. This is certainly possible, though a lot of information would need to be kept about the match already found (which is what I meant about things not working with the current backtracking system). Also, you must ensure that the testing stops when you hit the second terminal, for two reasons – first, not doing so would imply that all terminals are checked, and second, the test to distinguish 4 from 5 could throw an exception. For similar reasons, the return value of the third terminal can't be computed – it could be a very long computation, or it could throw an exception.

If the correct terminal is the second one, we will return the second one. No information needs to be kept around. I suggest you take a closer look at the code at this point.

Aah, you're right. (I think.) Might it be more accurate to say that the situation I proposed can't happen? That is, no two trees are created where there are lower-numbered terminals in the second tree than in the first tree?

Is the plan to add backtrack points for everything where equality can't be determined at compile time?

These patches implement the proper backtracking for tests that are not mutually exclusive.

Wow, this is great. I've skimmed over the patches and they look pretty good. I will go over them more closely as soon as I can - there are a couple changes we should probably make. Thanks!

No problem. My apologies for the persistent misunderstanding.

Sorry for the epic delay. Here are my notes on that patches:

1. Let's rename mutually-exclusive-inequality? to comparable?
2. I want GuardPatterns to comparable, I'm not going to support arbitrary fns - not worth it IMO.
As a compromise I'd be willing to rename :when patterns -> PredicatePatterns and GuardPatterns
can be allowed via :guard.
3. No need to declare OrPatterns as comparable - they aren't real patterns
4. No need to exclude VectorPatterns - the way that pattern matching works makes this unnecessary

If you make these changes I promise to apply these in a timely manner

Okay, patch uploaded. There is a fairly significant portion of it that is just cut and paste, which I'm not so happy about, but I don't think there's a way to do type inheritance, so I did the easier thing.

Fixed, https://github.com/clojure/core.match/commit/ac92c6df3f70f56fbe12f9d3f46585e66102c50b

addressed MATCH-50

Fixed, https://github.com/clojure/core.match/commit/1399a77e7833abb3a41be538a6356bc3bd871152

Another example of (I think) the same issue:

user=> (let [x ()] (match [x] [([h & t] :seq)] [h t] [_] :a1))
[nil ()]

Perhaps SeqPattern's IPatternCompile should call seq in order to filter empty seqs? (e.g.:

(to-source* [this ocr]
`(and (or (seq? ~ocr) (sequential? ~ocr)) (seq ~ocr)))

(match [x]
  [^Foo {.-bar 5 .-baz 7}] :a0
  [^Foo {.-bar _ .-woz 8}] :a1
  :else :a2)

Given the recent ClojureScript property access discussions this seems like an acceptable syntax for high-performance property access.

Maybe:

(match [^Foo x]
  [{.-bar 5 .-baz 7}] :a0
  [{.-bar _ .-woz 8}] :a1
  :else :a2)

But probably not since then we should probably throw if someone tries to declare a different type in the row.

Continuing the conversation from GitHub - concerning your changes, we should probably show what current occurrence failed to match as well as the breadcrumb.

Matching diagnostics will be complicated by MATCH-1. Clojure doesn't yet support simple data conveying exceptions. Will probably have to use a combination of proxy and definterface.

I haven't yet kept up with your backtracking changes, and I just noticed this conversation, so I'll have to have another look at diagnostics with backtracking.

(match x
  ({:c 1} :has [:a :b]) :a0
  ...)

or

(match x
  ({:c 1} :contains [:a :b]) :a0
  ...)

Seems reasonable.

Ah misunderstood. You want something like :allowed.

Clojure 1.3

Thanks for the report. The patch is not going to work - we should be checking that the vector has at least one item.

with Clojure 1.3

https://gist.github.com/626088b01817ac638fae
Two expressions, macro-expanded. The only difference between the expressions is that the second occurrence in the second expression is seq'ed. The second let is the one throwing the exception; it's the one with the binding

(clojure.core/let [q_tail_3472 q_tail_3472
q_head_3471 q_head_3471
ocr-3470 (seq y)
z z]
...)

core.match 0.2.0-alpha10 and 0.2.0-alpha11-SNAPSHOT (git 7ad66cc)
clojure 1.3.0 and 1.4.0

I can confirm the same issue on alpha11.

I believe I may have found the cause and have fixed master - if someone can confirm I'll happily cut another release.

http://github.com/clojure/core.match/commit/cbcc6e5fa070a7025e72f5eab4e83eaec100332b

Thanks David,

That change has not fixed the issue for me.

So the pattern parameter being passed to dag-clause-to-clj:

(defn dag-clause-to-clj [occurrence pattern action]
  (let [test (if (instance? clojure.core.match.IPatternCompile pattern)
               (to-source* pattern occurrence)
               (to-source pattern occurrence))]
...

is a WildcardPattern which doesn't implement IPatternCompile and doesn't have a to-source method. So it seems it shouldn't be passed at all. Indeed, in normal usage it isn't.

;; ## Wildcard Pattern
;; 
;; A wildcard pattern accepts any value.
;;
;; In practice, the DAG compilation eliminates any wildcard patterns.

(defprotocol IWildcardPattern
  (sym [this]))

(deftype WildcardPattern [sym _meta]
  IWildcardPattern
  (sym [_] sym)
  clojure.lang.IObj
  (meta [_] _meta)
  (withMeta [_ new-meta]
    (WildcardPattern. sym new-meta))
  Object
  (toString [_]
    (str sym)))

Can you include an example pattern which works under normal circumstances but fails under AOT? This must meant that WildcardPatterns are making it through under AOT and getting to the multimethod case but not under incremental compilation at the REPL.

This seems to do it:

(match {}
  {:a :x :b b} :dummy
  :else :dummy)

I've seen this problem as well. If I try to compile a second time, however, without running lein clean, the compilation succeeds. Maybe it's a bootstrapping problem?

tested on 0.2.0-alpha10-SNAPSHOT

"non-working" meaning that the match always drops directly the :else clause.

Updated code to minimal example. Problem persists with both Lein 1.7 and cake 0.6.3

AOT bugs are a bit tricky to track down. Not sure how soon I'll be able to really dive into this one.

Clojure 1.3

Leiningen 1.7.1 on Java 1.6.0_26

core.match "0.2.0-alpha9"

All AOT related issues w/o patches are low priority for the foreseeable future. They are simply too time consuming to track down and I don't have the bandwidth at the moment. I will get to them eventually, but if you want movement on this please submit a patch. I will happily apply it!

Hey David,

After going through the source code and some more in depth look I managed to understand what was going on, first iv stepped through the different stages

(def m (emit-matrix ['body]
'( [(['when & r] :seq)] (lhs r)
[(['accumulate & r] :seq)] (<< "accumulate(~(lhs r))")
[([bind ':> & r] :seq)] (<< "~{bind}:~(lhs r)"); pattern with bind
[([(t :when is-type?) & r] :seq)] (<< "_{t}(lhs r)"); pattern
[([([(f :when acc-fn?) & args] :seq) & r] :seq)] (<< ",_{f}{args}~(lhs r)" ); accumulate function
[([':from dest & r] :seq)] (<< "from ~(lhs dest) ~(lhs r)")
[([':over win & r] :seq)] (<< "over ~(window win) ~(lhs r)")
[([([(o :when operator?) f s] :seq) :as c & r] :seq)] (<< "(~(reduce str (map pr-str (to-infix c)))) ~(lhs r)")
[(['entry-point point & r] :seq)] (<< "entry-point \"~{point}\"~(lhs r)")
:else ""
)))

(def c (cm/compile m))

(pprint c)

(pprint (executable-form c))

The last pprint failed aot compilation:

$ lein compile

...
Caused by: java.lang.ClassCastException: clojure.core.match.WildcardPattern cannot be cast to java.lang.String

Which was very weird as I could clearly see that:

(deftype WildcardPattern [sym _meta]
IWildcardPattern
(sym [_] sym)
clojure.lang.IObj
(meta [_] _meta)
(withMeta [_ new-meta]
(WildcardPattern. sym new-meta))
Object
(toString [_]
(str sym)))

Then iv also tried to enabled trace:

(set-trace! true)

Which resulted with:

$ lein compile

...

TRACE: DAG: Column 0 : [#<SeqPattern #<LiteralPattern window> #<LiteralPattern :time> #<WildcardPattern t> #<WildcardPattern unit>>]
TRA at clojure.lang.Compiler.analyzeSeq(Compiler.java:6416)
at clojure.lang.Compiler.analyze(Compiler.java:6216)
at clojure.lang.Compiler.analyze(Compiler.java:6177)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5572)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5008)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3629)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6407)
at clojure.lang.Compiler.analyze(Compiler.java:6216)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6397)
at clojure.lang.Compiler.analyze(Compiler.java:6216)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:492)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6409)
at clojure.lang.Compiler.analyze(Compiler.java:6216)
at clojure.lang.Compiler.analyze(Compiler.java:6177)
at clojure.lang.Compiler.compile1(Compiler.java:6980)
at clojure.lang.Compiler.compile(Compiler.java:7046)
at clojure.lang.RT.compile(RTCE: DAG: Add switch-node on occurrence exp

The most weird thing was that on second compile it all went well, this raised a flag and my suspicion was that the core.match classes got compiled on the first run:

$ ls classes/

match$analyze_actions$analyze_action__1166.class
match$analyze_actions.class
match$backtrack_expr.class
match$bind_node.class
match$catch_error.class
match$check_matrix_args$check_pattern__1150.class
...

Then iv decided to AOT compile clojure.core match:

$ git checkout core.match-0.2.0-alpha9
$ git diff project.clj
-(defproject match "0.2.0-alpha10-SNAPSHOT"
+(defproject match "0.2.0-alpha10-aot"
:description "Optimized pattern matching and predicate dispatch for Clojure"
:source-path "src/main/clojure"

• :test-path "src/test/clojure")
  + :test-path "src/test/clojure"
  + :aot [clojure.core.match]
  + )

After using the aot jar it all went smooth including passing my non deterministic case (which is deterministic but very confusing to track down),

In order to reproduce it its important to run:

$ lein clean
$ rm -rf lib

And only then run

$ lein compile

Otherwise the classes dir might contain AOT'ed classes and make it seem that even non-aot jar works fine (its enough to run lein compile once to cause the classes to get compiled),

The fix in my case is simple, just AOT ns.

Im not sure if this Is a bug in the way Clojure AOT its classes but I think that adding the AOT'ed classes to the default core match distro is a reasonable workaround

BTW when using master (and not the tag) iv stumbled upon:

Exception in thread "main" java.lang.AssertionError: Assert failed: Unknown predicate in [is-type?]

Which is a pred defined in my ns.

FWIW, I've been using the patch described here, and haven't yet run into any problems, though I also haven't used core.match that much. Anyway, with the change to subvec-inline, both of the cases here act as expected (producing nil and :a, respectively).

(I note looking at my patch that I'm doubly-evaluating ocr in the second overload; obviously that should be fixed with a let binding).

The patch looks like it's going in the right direction. Can you explain why your patch without the pattern-compares case causes the second example to fail?