<< Back to previous view

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

Status: Closed
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: Declined Votes: 0
Labels: bug

[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"]


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 []
   (.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.

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 ""]
[org.clojure/core.match "0.2.0"]

Comment by David Nolen [ 10/Dec/14 11:42 AM ]

This is a core.async bug now core.match one.

[MATCH-61] Exception thrown when matching using :seq when there is a seq call in the tail of the occurrences Created: 22/Jun/12  Updated: 28/Jul/13  Resolved: 20/Jun/13

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

Type: Defect Priority: Major
Reporter: Emma Tosch Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bug, seq

with Clojure 1.3


The following match throws:

(let [q '(a) y '(b) z '(c)]
  (match [q (seq y) z]
    [([_] :seq) _ _] 'a
    [_ _ _] 'b))

Looking at the macro expansion there's something clearly wrong simply with the fact that the seq expression occurs in multiple places instead of just at the beginning of the macro expansion.

Comment by Emma Tosch [ 22/Jun/12 5:33 PM ]

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]

Comment by David Nolen [ 20/Jun/13 7:35 AM ]

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

Generated at Sun Apr 19 06:02:08 CDT 2015 using JIRA 4.4#649-r158309.