<< Back to previous view

[MATCH-109] Call `emit-pattern` and `to-source` to let'ed things. {code:clojure} (let [x "hello" y :foo x-regex #"Hello"] (match [x y] [x-regex y] :match :else :no-match)) {code} Created: 24/May/15  Updated: 31/May/15

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

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


 Comments   
Comment by David Rojas [ 24/May/15 9:16 PM ]

Apologies for the ugly description. This is my first time with this issue tracker.

Well, I want to extend `match` to my data structures but can't find yet how to make it call `emit-pattern` and `to-source` on them.

This is similar to how I was trying to do it (not with regexes).

(let [x "hello"
      y :foo
      x-regex #"hello"]
  (match [x y]
         [x-regex y] :match
         :else       :no-match))
Comment by David Rojas [ 24/May/15 10:09 PM ]

I've realised that this is not practical. However, how can I extend match to other types (other than java.util.regex.Pattern). I mean, for regexes the reader macro delivers an instance of Pattern directly to the matrix, but how to achieve the same for a type that doesn't have an analogous reader macro?.

Comment by Jan-Paul Bultmann [ 31/May/15 11:21 AM ]

I don't think this can't be done in genera, as it would allow the introduction of arbitrary patterns at runtime.

E.g.

Unable to find source-code formatter for language: clojure. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(let [x 1
      y :foo
      a-match '(1 | [1 [ 2 [3])]
  (match [x y]
         [a-match y] :match
         :else       :no-match))

However it should be possible to create a custom type that emits to code that takes a regex and a string and performs a match on them.





[MATCH-107] Map pattern with vector key raises "clojure.lang.PersistentVector cannot be cast to clojure.lang.Named" exception Created: 28/Apr/15  Updated: 28/Apr/15

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

Type: Defect Priority: Major
Reporter: Joshua Griffith Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: bug
Environment:

Java 1.8.0_11, Clojure 1.7.0-beta2, core.match 0.2.2 and 0.3.0-alpha4



 Description   

The following pattern throws "CompilerException java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Named":

(let [x {[1] 2}]
(match [x]
[{[1] _}] true))






[MATCH-106] variable binding fails with :or guard Created: 07/Apr/15  Updated: 07/Apr/15

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

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

Clojure 1.6.0, Emacs 24.2, OS X.



 Description   

The following works
fine:

```
(match ['F] [('F :as x)] x)
;; => F
```

But fails when I try to use an :or guard:

```
(match ['F] [((:or 'F 'T) :as x)] x)
;; CompilerException java.lang.RuntimeException: Unable to resolve symbol: x in this context
```






[MATCH-102] Do :guard predicates really need to handle :clojure.core.match/not-found? Created: 17/Dec/14  Updated: 17/Dec/14

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

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

Clojure 1.7.0 beta4, core.match 0.3.0-alpha3



 Description   

I'm very new to core.match and just started playing around. Doing so, I came up with this example:

(for [x [[1 2 3]
	 [1 2 3 4]
	 {:a 17, :b 2}
	 {:a 23, :b 7}]]
  (match [x]
   [[a b c]]                    [a b c]
   [{:a a, :b 2}]               {:a a}
   [{:a (a :guard odd?), :b b}] {:a a, :b b}
   :else                        :no-match))

This errors with the message "IllegalArgumentException Argument must be an integer: :clojure.core.match/not-found clojure.core/even? core.clj:1351)". The problem is that the keyword :clojure.core.match/not-found is passed to the :guard function odd? which passes it to even?.

I can fix it by ensuring the my guard only gets an integer like so:

(for [x [[1 2]
        [1 2 3]
        [1 2 3 4]
        {:a 17, :b 2}
        {:a 23, :b 7}]]
  (match [x]
   [[a b c]]                               [a b c]
   [{:a a, :b 2}]                          {:a a}
   [{:a (a :guard #(and (integer? %)
                        (odd? %))), :b b}] {:a a, :b b}
   :else                                   :no-match))

But is it really intensional that guards have to deal with :clojure.core.match/not-found? In my opinion, in the example above all maps that are matched have integer values, so it seems plausible that I can have a guard that only accepts integers.



 Comments   
Comment by Tassilo Horn [ 17/Dec/14 7:34 AM ]

You can actually use that :clojure.core.match/not-found special value to make a kind of perverted map pattern that matches only if it doesn't match like so.

(match [{:a 1}]
  [{:b (a :guard #(identical? % :clojure.core.match/not-found))}] :yes
  :else                                                           :no)
;=> yes

But I guess (and hope) nobody relies on such a strange behavior.





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

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

Comment by Jan-Paul Bultmann [ 12/Apr/15 6:14 PM ]

Some weirdness is also going on with `&` in vectors.

This is the working vector matching behaviour without `&`.

(match [[1 2 3]]
[([u v w] :as a)] a)
=> [1 2 3]

And this is the result of adding a rest match.

(match [[1 2 3]]
[([h & r] :as a)] a)
=> [1]

Both should be the same.





[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-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-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-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-65] cata matching Created: 23/Nov/12  Updated: 12/Dec/14

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   

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



 Comments   
Comment by David Nolen [ 10/Dec/14 12:38 PM ]

Similar to function application except that if a function call throws a no match exception, catch and backtrack.

Comment by David Nolen [ 12/Dec/14 4:18 PM ]

Going to de-prioritize for now as matching on function applications delivers a lot of power as is.





[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-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-4] Optimized pattern matching on deftype/record, POJOs Created: 04/Sep/11  Updated: 10/Apr/15

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: 1
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.

Comment by Leonardo Borges [ 08/Apr/15 2:12 AM ]

Is it worth me picking this up?

I've implemented a very rudimentary version of this that I'm using here: https://github.com/leonardoborges/imminent#pattern-matching

Would love to see this extended and officially supported though. Thoughts?

Comment by David Nolen [ 08/Apr/15 7:53 AM ]

Yes happy to see someone pick this up.

Comment by Leonardo Borges [ 08/Apr/15 9:00 PM ]

Excellent! Would you have any pointers/guidelines? If not, I'll just go from first principles using what's described in https://github.com/clojure/core.match/wiki/Advanced-usage#participating-in-pattern-matching

Comment by David Nolen [ 10/Apr/15 5:12 PM ]

Yeah the primary issue is just figuring out a good syntax for it. Once that's in place I don't think getting it working will be so hard.





Generated at Tue Aug 04 06:55:12 CDT 2015 using JIRA 4.4#649-r158309.