<< Back to previous view

[MATCH-31] vector patterns should work on seq Created: 10/Oct/11  Updated: 24/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 1
Labels: None


 Description   

This means abandoning subvec and using nth + offsets.






[MATCH-78] Switches on literals should happen via `case` not `cond` Created: 25/Jun/13  Updated: 25/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It worth investigating whether this improves performance at all.






[MATCH-79] Tidy up for 0.2.0, add comprehensive doc strings Created: 25/Jun/13  Updated: 25/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None





[MATCH-40] Allow or'ing of guard functions Created: 21/Nov/11  Updated: 21/Nov/11

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Hugo Duncan Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In order to simplify composition of guard predicates which are alternatives, allow for passing a sequence of predicates whose values when called will be or'd together.

The :when keyword currently allows passing of a vector of predicates that are and'd together.

Either case (`and` or `or`) can be achieved externally to match via composition, and an alternative might be to force explicit composition outside of core.match.

At the least, the documentation should mention that multiple predicates will be and'd together.






[MATCH-49] Duplicate wildcard detection in pattern row doesn't account for locals Created: 12/Jan/12  Updated: 12/Jan/12

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None





[MATCH-75] rest patterns don't work on arrays Created: 20/Jun/13  Updated: 20/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently they simply don't work. When we make it work we should probably wrap the array in something like ArraySeq. We might want to consider support for unwrapping ArraySeq. We need to carry type information as well as offset information.






[MATCH-74] pass occurrence to emit-pattern Created: 20/Jun/13  Updated: 20/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently we have a hack to read type information at vector pattern specialization time overriding whatever the :t field is for a VectorPattern instance. We should instead pass the occurrence to emit-pattern so the vector-pattern can start with the correct type information.






[MATCH-4] Optimized pattern matching on deftype/record, POJOs Created: 04/Sep/11  Updated: 11/Aug/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   
(match [x]
  [({:a 0 :b 1} :type Foo)] :a0
  ...)

:a and :b would be converted to field access, i.e. (.a x)

As with primitive array matching, we should do an instance check followed by hinted field access.

We should consider adopting the deftype/record syntax.



 Comments   
Comment by David Nolen [ 27/Oct/11 4:41 PM ]
(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.

Comment by Ron Pressler [ 10/Aug/13 4:57 PM ]

Hi. Any plans on resolving this?

Comment by David Nolen [ 11/Aug/13 10:55 AM ]

I have no specific timeline, it will definitely be after 0.2.0, only focusing on bugs at the moment.





[MATCH-90] ignore duplicate wildcard check if matching a local multiple times in same pattern row Created: 19/Nov/13  Updated: 19/Nov/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   
(let [v 10]
  (match x
    [v v v] ...))





[MATCH-95] recur detection logic is too naive Created: 16/Apr/14  Updated: 17/Apr/14

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The following explodes because of the presence of recur:

(defn rec [expr]
  (match expr
         [:global] 'GLOBAL
         [:constant x] x
         [:variable x] x
         [:lazy-variable x] `(deref ~x)
         [:if test if-true if-false] `(if ~(rec test)
                                        ~(rec if-true)
                                        ~(rec if-false))
         [:delist list index] `(get ~(rec list) ~(rec index))
         [:depair pair key] `(get ~(rec pair) ~(match key :first 0 :second 1))
         [:list elements] (map rec elements)
         [:fold-recur index-arg list-sym] `(recur (+ 1 ~index-arg) (rest ~list-sym))
         [:zip left right] `(map vector ~(rec left) ~(rec right))
         [:filter list arg body] `(filter (fn [~arg] ~(rec body) ~(rec list)))
         [:len list] `(count ~(rec list))
         [:pair first second] [(rec first) (rec second)]
         [:block arg body] `(fn [~arg] ~(rec body))
         [:app f arg] `(~(rec f) ~(rec arg))
         [:query e annotations] `(QUERY ~(rec e) ~annotations)
         [:lookup key] `(LOOKUP ~key)
         [:let name value expr] `(let [~name ~value] expr)
         ; ... about 15 more
         ))


 Comments   
Comment by Jeanine Adkisson [ 17/Apr/14 1:52 PM ]

A hacky workaround is to interpolate the 'recur symbol from an outer scope.

(def recur-sym 'recur)

(match expr
  ... `(~recur-sym ...))
Comment by David Nolen [ 17/Apr/14 1:58 PM ]

Now that tools.analyzer exists it won't be difficult to solve this properly.





[MATCH-97] satisfies? calls for IMatchLookup perf issues Created: 10/Sep/14  Updated: 10/Sep/14

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently when pattern matching trees IMatchLookup is a performance liability due to it's slowness on failure. Probably need think about a way to opt-in?






[MATCH-93] Simple capturing of :or matches with :as doesn't work Created: 30/Jan/14  Updated: 10/Sep/14

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Chas Emerick Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

All three of these expressions should work (according to @dnolen in IRC):

user> (match/match [5] [((:or 5 6) :as x)] x)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: x in this context
user> (match/match [5] [(:or (5 :as x) (6 :as x))] x)
5
user> (match/match [5] [(:or (5 :as x) (6 :as y))] x)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: x in this context

(The first makes sense to me, but the latter two don't; e.g. should y be nil in the last example, or something else?)

Though it's not necessary, it'd be nice if the following "sugared" form worked, too:

user> (match/match [5] [(:or 5 6 :as x)] x)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: x in this context


 Comments   
Comment by Greg Chapman [ 10/Sep/14 4:04 PM ]

Same problem occurs with :guard patterns:

user=> (match/match 1 ((_ :guard odd?) :as n) n :else 0)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: n in this context





[MATCH-9] use case for dispatching on literals Created: 04/Sep/11  Updated: 10/Oct/11

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Would speed up literal matching considerably.






[MATCH-8] Implement (p|q)ba heuristics Created: 04/Sep/11  Updated: 04/Sep/11

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should implement the rest of Maranget's suggested heuristics.

p - needed prefix
q - constructor prefix
b - branching factor
a - constructor arity






[MATCH-65] cata matching Created: 23/Nov/12  Updated: 15/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Dan Friedman's pattern matcher has a nice feature called cata-matching - allowing recursive matching from the match itself. Useful when writing compilers.






[MATCH-64] Improve match compile times Created: 15/Aug/12  Updated: 15/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None





[MATCH-2] Matching Diagnostics Created: 04/Sep/11  Updated: 16/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Communicate to the user precisely what failed to match. Conversation here: http://groups.google.com/group/clojure/browse_thread/thread/675456fba1712214. We adopt the behavior of condp since that is closer to what match does and will do (predicate dispatch)



 Comments   
Comment by David Nolen [ 05/Sep/11 10:40 AM ]

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

Comment by David Nolen [ 26/Sep/11 7:10 AM ]

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.

Comment by Ambrose Bonnaire-Sergeant [ 30/Sep/11 4:39 AM ]

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.

Comment by David Nolen [ 16/Jun/13 1:57 PM ]

Lowering priority. Happy to take a patch, but I don't think I'll be looking into this myself in the near future.





[MATCH-72] complexity analysis Created: 18/Jun/13  Updated: 18/Jun/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

For smaller matches avoid backtracking actually greatly improves performance at the potential cost of code size. Perhaps we can devise a heuristic such that we employ the the best option available? Would need some serious hammock time.






[MATCH-89] perf 3x slower for ragged rows Created: 27/Oct/13  Updated: 28/Oct/13

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: kovas boguta Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In both cases, match should fail immediately on seeing the first element.

Slow case:

(let [f
        (fn [x] (match x [1 1] 1 [2] 2 :else 3))]
    (time (dotimes [_ 100000] (f [3]))))
"Elapsed time: 57.899 msecs"

Fast case:

(let [f
        (fn [x] (match x [1 1] 1 [2 _] 2 :else 3))]
    (time (dotimes [_ 100000] (f [3]))))
"Elapsed time: 16.998 msecs"


 Comments   
Comment by David Nolen [ 27/Oct/13 8:24 PM ]

Ragged rows are hard to optimize. We used to try and intelligently group patterns - but this "optimization" created an incredible number of edgecase bugs. So until I or someone else can come up with a sound way to do this, going to continue to punt on this.

Comment by kovas boguta [ 28/Oct/13 6:03 PM ]

Can you point commit where that optimization existed? Just want to get a sense of what code path are affected.

Comment by David Nolen [ 28/Oct/13 9:08 PM ]

If you look at the repo tree around the first 0.2.0 alpha you'll see it, however the optimization was not global - it was a specific thing for each type of pattern. Again, I'm not particularly inclined to revisit this myself, but if you have a clever idea how it can be done without the previous problems I'm all for it.





[MATCH-87] Bad interaction with core.async Created: 11/Sep/13  Updated: 01/Dec/13

Status: Reopened
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Stefan Fehrenbach Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: bug
Environment:

[org.clojure/core.async "0.1.0-SNAPSHOT"] (more specifically core.async-0.1.0-20130827.050117-78)
[org.clojure/core.match "0.2.0-rc5"]



 Description   

This prints "foo" as expected:

(defn works []
  (.log js/console
        (match ["qux" "foo"]
          ["qux" "bar"] 1
          ["qux" x]     x)))

This fails with an exception: Uncaught Error: No matching clause: ["qux" "foo"]
in up-to-date Chromium

(defn fails []
  (go
   (.log js/console
         (match (<! (go ["qux" "foo"]))
           ["qux" "bar"] 1
           ["qux" x]     x))))

I don't know either core.async nor core.match very well. My best guess is a undesired interaction between the nonlocal control flow for backtracking and the core.async state machine.

Note that this is a version of core.async where http://dev.clojure.org/jira/browse/ASYNC-15 is fixed.



 Comments   
Comment by David Nolen [ 11/Sep/13 12:24 PM ]

This is not a bug, it's not possible to use <! outside of go blocks.

Comment by Stefan Fehrenbach [ 11/Sep/13 12:48 PM ]

Does that count as outside? Anyway, this should not be outside. Same problem.

(defn fails []
  (go (let [m (<! (go ["qux" "foo"]))]
        (.log js/console
              (match m
                ["qux" "bar"] 1
                ["qux" x] x)))))
Comment by David Nolen [ 11/Sep/13 1:17 PM ]

Sorry missed the surrounding go! However note tickets about interaction between core.match and core.async are extremely low priority without more information about whether the bug is actually in ASYNC or in MATCH. I just don't have the bandwidth to do that sort of investigation at the moment.

Still, thanks for the report.

Comment by Stefan Fehrenbach [ 11/Sep/13 2:05 PM ]

I see. I'm not so sure whether I should report this to ASYNC, any thoughts?
I'm not familiar with either library, but I'll try to investigate further when I have the time.
For now, I guess I'll do more stupid matching. It really is a shame, core.match is a perfect fit for dispatching on messages and channels coming from alts!. Anyways, thanks for your work!

Comment by David Nolen [ 30/Nov/13 2:28 PM ]

Is this still a problem? I think core.async recently added better analysis of the dot form.

Comment by Stefan Fehrenbach [ 01/Dec/13 2:45 AM ]

Hi, thanks for thinking about this. I got side tracked and did not look into it any further.
Unfortunately it still does not work.

Tested versions:
[org.clojure/clojurescript "0.0-2080"]
[org.clojure/core.async "0.1.242.0-44b1e3-alpha"]
[org.clojure/core.match "0.2.0"]





[MATCH-7] Eliminate distinction between leaf-bind-expr and bind-expr Created: 04/Sep/11  Updated: 21/Oct/11

Status: Open
Project: core.match
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Trivial
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should have a better considered binding model that works for all cases instead of treating leaf nodes and regular binding as different cases.






Generated at Wed Oct 22 21:42:28 CDT 2014 using JIRA 4.4#649-r158309.