<< Back to previous view

[LOGIC-116] ClassCastException in core.logic depending on ordering Created: 08/Mar/13  Updated: 28/Jul/13  Resolved: 17/Mar/13

Status: Closed
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: File corefail.clj    

 Description   

I have two files:
1 -https://github.com/m0smith/LogicPuzzles/blob/master/src/logicpuzzles/coresucceed.clj
2 -https://github.com/m0smith/LogicPuzzles/blob/master/src/logicpuzzles/corefail.clj

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
at clojure.core$disj.invoke (core.clj:1420)
clojure.core.logic.ConstraintStore/fn (logic.clj:339)
clojure.lang.ArrayChunk.reduce (ArrayChunk.java:58)
clojure.core.protocols/fn (protocols.clj:94)
clojure.core.protocols$fn_5854$G5849_5863.invoke (protocols.clj:19)
clojure.core.protocols$seq_reduce.invoke (protocols.clj:31)
clojure.core.protocols/fn (protocols.clj:60)
clojure.core.protocols$fn_5828$G5823_5841.invoke (protocols.clj:13)
clojure.core$reduce.invoke (core.clj:6030)
clojure.core.logic.ConstraintStore.remc (logic.clj:338)
clojure.core.logic$remcg$fn__3272.invoke (logic.clj:2374)
clojure.core.logic$BANG$reify_3422.invoke (logic.clj:2719)
clojure.core.logic$composeg$fn__2569.invoke (logic.clj:1141)
clojure.core.logic$composeg$fn__2569.invoke (logic.clj:1142)
clojure.core.logic$run_constraint$fn__3285.invoke (logic.clj:2397)
clojure.core.logic$fix_constraints.invoke (logic.clj:2424)
clojure.core.logic$run_constraints$fn__3290.invoke (logic.clj:2434)
clojure.core.logic.Substitutions.bind (logic.clj:612)
clojure.core.logic$run_constraints_STAR_$fn__3296.invoke (logic.clj:2444)
clojure.core.logic.Substitutions.bind (logic.clj:612)
clojure.core.logic$run_constraints_STAR_$fn__3296.invoke (logic.clj:2446)
clojure.core.logic$EQEQ$fn__2647.invoke (logic.clj:1255)
clojure.core.logic.Substitutions.bind (logic.clj:612)
clojure.core.logic$rembero$fn_3465$_inc3466$fn3475$fn3476$_inc3477$fn3478$_inc_3479.invoke (logic.clj:2790)
clojure.core.logic$eval2628$fn_2633$_inc_2634.invoke (logic.clj:1223)
clojure.core.logic$eval2628$fn_2633$_inc_2634.invoke (logic.clj:1223)
clojure.core.logic$eval2628$fn_2637$_inc_2638.invoke (logic.clj:1220)
clojure.core.logic$eval2628$fn_2633$_inc_2634.invoke (logic.clj:1223)
clojure.core.logic$eval2628$fn_2633$_inc_2634.invoke (logic.clj:1223)
clojure.core.logic$eval2628$fn_2633$_inc_2634.invoke (logic.clj:1223)
clojure.core.logic$eval2628$fn_2637$_inc_2638.invoke (logic.clj:1220)
clojure.core.logic$eval2628$fn_2633$_inc_2634.invoke (logic.clj:1223)
clojure.core.logic$eval2628$fn_2637$_inc_2638.invoke (logic.clj:1220)
clojure.core.logic$eval2628$fn_2629$fn_2630.invoke (logic.clj:1225)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:67)
clojure.lang.RT.seq (RT.java:473)
clojure.core$seq.invoke (core.clj:133)
clojure.core$take$fn__4112.invoke (core.clj:2501)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:60)
clojure.lang.LazySeq.first (LazySeq.java:82)
clojure.lang.RT.first (RT.java:566)
clojure.core$first.invoke (core.clj:55)
clojure.pprint$pprint_reader_macro.invoke (dispatch.clj:50)
clojure.pprint$pprint_list.invoke (dispatch.clj:77)
clojure.lang.MultiFn.invoke (MultiFn.java:163)
clojure.pprint$write_out.invoke (pprint_base.clj:194)
clojure.pprint$pprint_vector$fn__7949.invoke (dispatch.clj:83)
clojure.pprint$pprint_vector.invoke (dispatch.clj:82)
clojure.lang.MultiFn.invoke (MultiFn.java:163)
clojure.pprint$write_out.invoke (pprint_base.clj:194)
clojure.pprint$pprint$fn__7359.invoke (pprint_base.clj:250)
clojure.pprint$pprint.invoke (pprint_base.clj:248)
clojure.pprint$pprint.invoke (pprint_base.clj:245)
logicpuzzles.corefail$show.invoke (corefail.clj:9)
logicpuzzles.corefail$eval3796.invoke (corefail.clj:153)
clojure.lang.Compiler.eval (Compiler.java:6511)
clojure.lang.Compiler.load (Compiler.java:6952)
user$eval971.invoke (NO_SOURCE_FILE:1)
clojure.lang.Compiler.eval (Compiler.java:6511)
clojure.lang.Compiler.eval (Compiler.java:6477)
clojure.core$eval.invoke (core.clj:2797)
clojure.main$repl$read_eval_print__6405.invoke (main.clj:245)
clojure.main$repl$fn__6410.invoke (main.clj:266)
clojure.main$repl.doInvoke (main.clj:266)
clojure.lang.RestFn.invoke (RestFn.java:1096)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__544.invoke (interruptible_eval.clj:56)
clojure.lang.AFn.applyToHelper (AFn.java:159)
clojure.lang.AFn.applyTo (AFn.java:151)
clojure.core$apply.invoke (core.clj:601)
clojure.core$with_bindings_STAR_.doInvoke (core.clj:1771)
clojure.lang.RestFn.invoke (RestFn.java:425)
clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:41)
clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn_585$fn_587.invoke (interruptible_eval.clj:171)
clojure.core$comp$fn__4034.invoke (core.clj:2278)
clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__578.invoke (interruptible_eval.clj:138)
clojure.lang.AFn.run (AFn.java:24)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:615)
java.lang.Thread.run (Thread.java:722)

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: 28/Jul/13  Resolved: 02/Jan/13

Status: Closed
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: 28/Jul/13  Resolved: 02/Jan/13

Status: Closed
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





Generated at Tue Jul 29 17:55:24 CDT 2014 using JIRA 4.4#649-r158309.