corefail.clj
[LOGIC-116] ClassCastException in core.logic depending on ordering Created: 08/Mar/13 Updated: 17/Mar/13 Resolved: 17/Mar/13 |
|
| Status: | Resolved |
| Project: | core.logic |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Major |
| Reporter: | Matthew O. Smith | Assignee: | David Nolen |
| Resolution: | Completed | Votes: | 0 |
| Labels: | 0.8.0, bug | ||
| Attachments: |
corefail.clj
|
| Description |
|
I have two files: The first one compiles and runs fine. The second throws a ClassCastException. The only difference is that rule-0 is moved in the second file. |
| Comments |
| Comment by David Nolen [ 11/Mar/13 7:40 AM ] |
|
There's far too much context here. Do you have a minimal case? Thanks much! |
| Comment by Matthew O. Smith [ 11/Mar/13 9:15 AM ] |
|
Here is the stack trace. I will try to narrow it down further. java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast to clojure.lang.IPersistentSet |
| Comment by Matthew O. Smith [ 11/Mar/13 9:24 AM ] |
|
I tightened up the fail case https://github.com/m0smith/LogicPuzzles/blob/master/src/logicpuzzles/corefail.clj . Is that enough? |
| Comment by David Nolen [ 11/Mar/13 10:17 AM ] |
|
Thanks can you add the failing code to the ticket as an attachment? Thanks. |
| Comment by Matthew O. Smith [ 11/Mar/13 6:23 PM ] |
|
corefail.clj exhibits the error |
| Comment by David Nolen [ 17/Mar/13 6:29 PM ] |
|
fixed, http://github.com/clojure/core.logic/commit/7e4d0b6b71707e248fd4d0de3f6c090b50a18624 |
[LOGIC-89] Allow application again in pattern matches Created: 01/Jan/13 Updated: 07/Jan/13 |
|
| Status: | Open |
| Project: | core.logic |
| 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: | 0.8.0 | ||
| Description |
|
Perhaps we can support simple function application in the following manner. (defne substo [e new a out] (['(var ~a) _ _ new]) (['(var ~y) _ _ '(var ~y)] (nom/hash a y)) (['(app ~rator ~rand) _ _ '(app ~rator-res ~rand-res)] (substo rator new a rator-res) (substo rand new a rand-res)) (['(lam ~(nom/tie c body)) _ _ '(lam ~(nom/tie c body-res))] (nom/hash c a) (nom/hash c new) (substo body new a body-res))) If we have a seq in an unquote then we know we have an application. All function symbols are left alone, all arguments are considered to be fresh vars or locals. |
[LOGIC-88] disequality reification is broken Created: 29/Dec/12 Updated: 02/Jan/13 Resolved: 02/Jan/13 |
|
| Status: | Resolved |
| Project: | core.logic |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Blocker |
| Reporter: | David Nolen | Assignee: | David Nolen |
| Resolution: | Completed | Votes: | 0 |
| Labels: | 0.8.0 | ||
| Description |
(run* [q]
(fresh [x y]
(!= [1 x] [y 2])
(== q [x y])))
Does not return the following expected reified value: (([_0 _1] :- (!= [_0 2] [_1 1]))) Even more bizarre things happen with the following: (run* [q]
(fresh [x y z]
(!= [1 x z] [y 2 3])
(== q [x y])))
z leaks out in the reified value. (run* [q]
(fresh [x y z]
(!= [1 x z] [y 2 3])
(== q [x y z])))
We only see one var constraint in the reified value. |
| Comments |
| Comment by David Nolen [ 02/Jan/13 6:43 PM ] |
|
fixed, http://github.com/clojure/core.logic/commit/5a0eb2754dc744e60ea1c4ea3460b5429685ef59 |
[LOGIC-53] core.logic converts defrecords to maps in it's query results Created: 18/Sep/12 Updated: 02/Jan/13 Resolved: 02/Jan/13 |
|
| Status: | Resolved |
| Project: | core.logic |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Blocker |
| Reporter: | Martin Trojer | Assignee: | David Nolen |
| Resolution: | Completed | Votes: | 0 |
| Labels: | 0.8.0 | ||
| Environment: |
0.7.5 or 0.8-alpha |
||
| Description |
(defrecord Test [a b])
(run* [q]
(== q (->Test 1 2 )))
;; ({:a 1, :b 2})
;; Where's my record?
|
| Comments |
| Comment by David Nolen [ 19/Sep/12 12:02 PM ] |
|
Records are IPersistentMaps. core.logic doesn't know anything about your custom type so it returns the type it knows how to unify. If you want core.logic to work with your record you need to implement the unification protocols for you record. But of course that's a little tedious if you have many different records. Open to better ideas. The relevant code where this unexpected behavior occurs is the implementation of IWalkTerm for the core Clojure data types. |
| Comment by David Nolen [ 02/Jan/13 7:18 PM ] |
|
fixed, http://github.com/clojure/core.logic/commit/bd3f13a1cd3214e5e15e52383b49f0a54ec8a502 |