<< Back to previous view

[LOGIC-91] nom/tie and spurious reification of predc constraint Created: 02/Jan/13  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: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   
(is (= (run* [q]
           (nom/fresh [a]
             (fresh [x]
               (predc x number? `number?)
               (== x 1)
               (== (nom/tie a [a x]) q))))
        [(nom/tie 'a_0 '(a_0 1))]))
  (is (= (run* [q]
           (nom/fresh [a]
             (fresh [x]
               (== x 1)
               (predc x number? `number?)
               (== (nom/tie a [a x]) q))))
        [(nom/tie 'a_0 '(a_0 1))])) ;; false b/c of extra :- number? constraint


 Comments   
Comment by Nada Amin [ 02/Jan/13 5:07 AM ]

Implementing -force-ans in Tie

clojure.core.logic.IForceAnswerTerm
  (-force-ans [v x]
    (force-ans (:body v)))

resolves the test above, but not this one:

(is (= (run* [q]
           (nom/fresh [a b c]
             (fresh [x y]
               (== x 1)
               (predc x number? `number?)
               (== (nom/tie b (nom/tie a [a x])) (nom/tie c q)))))
        [(nom/tie 'a_0 '(a_0 1))])) ;; still false b/c of extra :- number? constraint
Comment by David Nolen [ 02/Jan/13 8:15 AM ]

This issue actually impacts any "single shot" constraint that implements `-relevant?` as simply returning `true`. The problem is that the `cgoal` constraint wrapper checks `runnable?`, runs the constraint, and then checks `relevant?` and if that's true adds the constraint even though it may very well may be entailed!

There are 6 constraints (1 of them the `defc` macro) which implement `-relevant?` as returning `true`. I think we should have more support (a protocol) for constraints which are essentially "single shot" and don't need to bother with implementing the `IRelevant` protocol.

For some background - the CLP(FD) constraints benefit most from the `IRelevant` protocol, where the constraints involve up to 3 terms and a considerable amount of propagation work may be avoided by doing some checking up front.

Comment by Nada Amin [ 02/Jan/13 8:19 AM ]

Hi David,

I have a fix proposed in pull request https://github.com/clojure/core.logic/pull/15

The idea there is that to honor single-shot constraints, we only need to honor the (remcg this) that they contain. This is only possible if they have proper ids. That's what I fix.

Let me know what you think.

Comment by David Nolen [ 02/Jan/13 8:46 AM ]

fixed, http://github.com/clojure/core.logic/commit/020f730429d71315f752ea51abad20dca896c8b0





[LOGIC-90] These three FD constraints seem to diverge with certain domains Created: 01/Jan/13  Updated: 28/Jul/13  Resolved: 01/Jan/13

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

Type: Defect Priority: Blocker
Reporter: Gary Fredericks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

clojure 1.5.0-beta1, core.logic 0.8.0-beta4



 Description   

This code:

(run 1 [a b c d]
     (infd a b c d (interval 0 3))
     (<fd a b)
     (<fd c d)
     (<fd d a))

returns

([2 3 0 1])
as expected. However, if we change the interval to (interval 0 4) it seems to diverge. The behavior is the same between (domain 0 1 2 3) and (domain 0 1 2 3 4).



 Comments   
Comment by David Nolen [ 01/Jan/13 1:45 PM ]

fixed, http://github.com/clojure/core.logic/commit/7ea49dffb057df6775a5b98d869bfef44ae83ec9





[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-95] disequality Created: 04/Jan/13  Updated: 28/Jul/13  Resolved: 04/Jan/13

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

Type: Defect Priority: Blocker
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File diseq.diff    

 Description   

This snippet wrongly succeeds with the result:

(([foo _0] :- (!= (foo _0))))

(run* [q]
      (nom/fresh [a b]
        (fresh [x y]
          (!= x y)
          (== (nom/tie a (nom/tie b [b y])) (nom/tie b (nom/tie a [a x])))
          (== x 'foo)
          (== [x y] q))))

Moving the disequality anywhere further down makes the snippet rightly fail.



 Comments   
Comment by Nada Amin [ 04/Jan/13 5:47 AM ]

An insight: if I remove the -relevant-var? protocol from !=c in core.logic, then this works and all other tests pass. Of course, this probably has performance applications, so thinking of alternatives.

Comment by Nada Amin [ 04/Jan/13 8:00 AM ]

The problem is not specific to nominal disequality. Here is the same bug with only core.logic:

(run* [q]
    (fresh [x y w z]
      (!= x y)
      (!= w z)
      (== z y)
      (== x 'foo)
      (== y 'foo)))

This should fail, because x == y == 'foo, but instead we get:

(_0 :- (!= (_1 foo)) (!= (foo foo))))
.

The problem is that var-rands takes the substitution map into account, while -relevant-var doesn't.

Comment by Nada Amin [ 04/Jan/13 8:31 AM ]

Another way disequality is broken:

(run* [q]
  (fresh [x y w z]
    (!= x [y])
    (== x ['foo])
    (== y 'foo)))

This snippet should fail, but instead returns '(_0). This is because y is not returned by recover-vars.

Comment by Nada Amin [ 04/Jan/13 11:18 AM ]

diseq.diff contains detailed commit message explaining the issues, fixes, and tests.

Comment by David Nolen [ 04/Jan/13 11:23 AM ]

fixed, http://github.com/clojure/core.logic/commit/fb489298417c643fdd03efbf6951e998e6821910





[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





[LOGIC-23] Locals not available in matche Created: 08/Dec/11  Updated: 28/Jul/13  Resolved: 09/Dec/11

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

Type: Defect Priority: Major
Reporter: Ryan Senior Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

clojure 1.2.1, core.logic 0.6.6


Attachments: Text File 46b1fa5af0678ae69d304a1e6b12393b3f87ac9c.patch     Text File 921538ed513b0f5045d63004948088b4ae6c28e2.patch    
Patch: Code and Test

 Description   

Ran into an issue with the fix for LOGIC-21. Locals used inside of a matche clause were not recognized as existing and new fresh values were assigned instead.

(defn locals-membero [x l]
  (matche [l]
          ([[x . tail]])
          ([[head . tail]]
             (membero x tail))))

In the above example, x was not found in locals and a new fresh value was assigned, giving incorrect results. A fix for the issue is attached.



 Comments   
Comment by Ryan Senior [ 08/Dec/11 6:16 PM ]

Fixed typo on the locals-membero test function

Comment by David Nolen [ 09/Dec/11 12:23 PM ]

Fixed, https://github.com/clojure/core.logic/commit/858583237c77c142a2a4e49ba7b6c11f072ef503





[LOGIC-82] conso and seq, when unifying tail later Created: 20/Dec/12  Updated: 28/Jul/13  Resolved: 20/Dec/12

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

These two snippets should both succeed, but the second one fails.

(run 1 [q]
  (fresh [a c]
    (conso a nil c)
    (== `(~a) c))) ;; '(_0)
(run 1 [q]
  (fresh [a b c]
    (conso a b c)
    (== b nil)
    (== `(~a) c))) ;; expected: '(_0), actual: '()


 Comments   
Comment by David Nolen [ 20/Dec/12 11:50 PM ]

It boggles the mind how this is just being discovered

Fixed, http://github.com/clojure/core.logic/commit/0c985df0236037907852f9b19c7df3ba6a607875





[LOGIC-120] (unify '[?x 1]) throws IllegalArgumentException Created: 14/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: Jonas Enlund Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File LOGIC-120.diff    

 Description   

The following two expressions throws IllegalArgumentException Don't know how to create ISeq from: java.lang.Long:

(unify '[?x 1])

(unifier '[?x 1])

The same thing happens for any non-sequential form.



 Comments   
Comment by Jonas Enlund [ 16/Mar/13 2:06 AM ]

The patch LOGIC-120.diff also incorporates the patch I submitted for LOGIC-121 as the approach taken doesn't work without that issue fixed.

Comment by David Nolen [ 17/Mar/13 11:40 AM ]

Patch applied from LOGIC-122

fixed,
http://github.com/clojure/core.logic/commit/2bf23fd1ea64966bae094c9f634dfb21ddd386d1





[LOGIC-29] Indexed relations return incorrect results for partially ground values Created: 04/Mar/12  Updated: 28/Jul/13  Resolved: 04/Mar/12

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

Type: Defect Priority: Major
Reporter: Brian Goslinga Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Consider the following code:
(defrel rel1 ^:index a)
(fact rel1 [1 2])
(run* [q] (fresh [a] (rel1 [q a]) (== a 2)))

The result of the above query is () although it should be (1). If the index is dropped, the correct result is returned.



 Comments   
Comment by David Nolen [ 04/Mar/12 3:46 PM ]

Fixed, https://github.com/clojure/core.logic/commit/773f13c3e92bb0eb658781b73fa6b02d1ec5008f





[LOGIC-49] minimal map type for unifying only part of a map Created: 31/Aug/12  Updated: 28/Jul/13  Resolved: 12/Oct/12

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

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

Attachments: File 49-partial-map.diff     File 49-partial-map.diff     Text File 49-partial-map.patch    

 Description   

currently it's a bit obnoxious that map unification must be over the entire map. It would be useful to have a new datatype - partial-map this would allow us to only match part of a map instead of the whole thing. Is this unsound?



 Comments   
Comment by Kevin Lynagh [ 12/Oct/12 12:44 PM ]

How do you feel about letting partial map have a value meaning "don't unify with a map that has a key here". E.g.,

{:a ?x :b ?y} == {:a 1 :b 2 :c 3} => {:a 1 :b 2}

but

{:a ?x :b !_} == {:a 1 :b 2 :c 3} => nil

My use case is doing map matching + rewrites and in some cases I don't want a partial-map to match a map that already has some keys defined.

Comment by David Nolen [ 12/Oct/12 1:10 PM ]

Sure, but this is a separate ticket. Also it should be expressible via a normal goal - not-has-keyo or some such. Once that's done we can think about sugar.

Comment by Kevin Lynagh [ 12/Oct/12 1:16 PM ]

Also on the Github: https://github.com/lynaghk/core.logic/tree/partial-map

Comment by Kevin Lynagh [ 12/Oct/12 1:31 PM ]

Patch without !_ sugar.

Comment by Kevin Lynagh [ 12/Oct/12 1:47 PM ]

Add patch, not diff.

Comment by David Nolen [ 12/Oct/12 1:52 PM ]

fixed, http://github.com/clojure/core.logic/commit/9b340ea4fff2f4dad50b0f9631054e713b895fe8





[LOGIC-111] conda expression that no longer works in rc2 Created: 04/Feb/13  Updated: 28/Jul/13  Resolved: 13/Feb/13

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

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


 Description   
(run* [x]
  (conda 
    [succeed
      (project [x] succeed)
      (project [x] succeed)]))

This is issue was reported by the damp.ekeko developers.



 Comments   
Comment by David Nolen [ 13/Feb/13 2:56 PM ]

I'm surprised this one has gone unnoticed for so long, both conda and condu implementation were incorrect for the unit case. Fixed in master: http://github.com/clojure/core.logic/commit/1d1724bc66b344551619c32331393a811fe7714a





[LOGIC-84] make occurs-check a field Created: 24/Dec/12  Updated: 28/Jul/13  Resolved: 01/Jan/13

Status: Closed
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: Completed Votes: 0
Labels: None


 Description   

This way we can control occurs-check without worrying about laziness.



 Comments   
Comment by David Nolen [ 01/Jan/13 12:38 PM ]

fixed, http://github.com/clojure/core.logic/commit/3be00503588772c5ababd35f037a967fb00036e2





[LOGIC-121] Unifier fails on some nested forms Created: 14/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: Jonas Enlund Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File LOGIC-121.diff    

 Description   

The expression

(unifier '[((?x ?y)) ((1 2))])

returns the (invalid) result {?x 1}. Note that unify works as expected:

(unify '[((?x ?y)) ((1 2))])
=> ((1 2))


 Comments   
Comment by David Nolen [ 17/Mar/13 11:39 AM ]

patch applied from LOGIC-122

fixed, http://github.com/clojure/core.logic/commit/2bf23fd1ea64966bae094c9f634dfb21ddd386d1





[LOGIC-78] nominal unification inspired by alphaKanren Created: 16/Dec/12  Updated: 28/Jul/13  Resolved: 31/Dec/12

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

Type: Enhancement Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File nominal.diff    
Patch: Code and Test

 Description   

The new core.logic.nominal namespace implements the alphaKanren primitive fresh, tie and hash.
The tests also run the examples from the alphaKaren paper.

See https://github.com/clojure/core.logic/pull/12 for the patch in progress.

(Meta: Should I add the patch-in-progress now or wait until we finalize the review on GitHub?)



 Comments   
Comment by David Nolen [ 16/Dec/12 10:43 AM ]

We can continue discussing it on GitHub for now. Once we're both happy with it there, we can attach the patch here. Thanks.

Comment by Nada Amin [ 31/Dec/12 9:37 AM ]

nominal.diff patch with implementation + tests in own core.logic.nominal namespace.

Comment by David Nolen [ 31/Dec/12 10:14 AM ]

fixed, http://github.com/clojure/core.logic/commit/b46b8c077360095c72eaa00a6a4aa843dc9136ff





[LOGIC-105] java.lang.IllegalArgumentException: No single method: _id of interface: clojure.core.logic.IConstraintId found for function: -id of protocol: IConstraintId Created: 17/Jan/13  Updated: 28/Jul/13  Resolved: 18/Jan/13

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

Type: Defect Priority: Major
Reporter: Timo Westkämper Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: None
Environment:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)

Ubtunu 12.04 - 32 bit



 Description   

When compiling this project https://github.com/timowest/symbol with the master version of core.logic I run into the following stacktrace

Exception in thread "main" java.lang.IllegalArgumentException: No single method: _id of interface: clojure.core.logic.IConstraintId found for function: -id of protocol: IConstraintId, compiling:(clojure/core/logic.clj:177:5)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6566)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyze(Compiler.java:6321)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2668)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6559)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyze(Compiler.java:6321)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5707)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5138)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3750)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6557)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6547)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:528)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6559)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyze(Compiler.java:6321)
at clojure.lang.Compiler.eval(Compiler.java:6622)
at clojure.lang.Compiler.load(Compiler.java:7062)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.loadResourceScript(RT.java:352)
at clojure.lang.RT.load(RT.java:431)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5039.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4988.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:621)
at clojure.core$use.doInvoke(core.clj:5497)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at symbol.types$eval75$loading_4931auto___76.invoke(types.clj:9)
at symbol.types$eval75.invoke(types.clj:9)
at clojure.lang.Compiler.eval(Compiler.java:6618)
at clojure.lang.Compiler.eval(Compiler.java:6607)
at clojure.lang.Compiler.load(Compiler.java:7062)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.loadResourceScript(RT.java:352)
at clojure.lang.RT.load(RT.java:431)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5039.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4988.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$require.doInvoke(core.clj:5486)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at symbol.includes_test$eval69$loading_4931auto___70.invoke(includes_test.clj:9)
at symbol.includes_test$eval69.invoke(includes_test.clj:9)
at clojure.lang.Compiler.eval(Compiler.java:6618)
at clojure.lang.Compiler.eval(Compiler.java:6607)
at clojure.lang.Compiler.load(Compiler.java:7062)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.loadResourceScript(RT.java:352)
at clojure.lang.RT.load(RT.java:431)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5039.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4988.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$require.doInvoke(core.clj:5486)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at user$eval29$fn__50.doInvoke(NO_SOURCE_FILE:1)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:617)
at user$eval29.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6618)
at clojure.lang.Compiler.eval(Compiler.java:6608)
at clojure.lang.Compiler.eval(Compiler.java:6581)
at clojure.core$eval.invoke(core.clj:2852)
at clojure.main$eval_opt.invoke(main.clj:300)
at clojure.main$initialize.invoke(main.clj:319)
at clojure.main$null_opt.invoke(main.clj:354)
at clojure.main$main$fn__6676.invoke(main.clj:432)
at clojure.main$main.doInvoke(main.clj:429)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: No single method: _id of interface: clojure.core.logic.IConstraintId found for function: -id of protocol: IConstraintId
at clojure.lang.Compiler$InvokeExpr.<init>(Compiler.java:3422)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3629)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6561)
... 99 more
Subprocess failed



 Comments   
Comment by David Nolen [ 17/Jan/13 3:20 PM ]

Can you try again with master? What do you mean by "compiling" the project? Are you AOT'ing your project?

Comment by Timo Westkämper [ 17/Jan/13 3:23 PM ]

Still the same issue. I am running 'lein midje'.

Comment by David Nolen [ 17/Jan/13 3:30 PM ]

So you are testing with Midje? Is there anyway to confirm that this issue exists if you take Midje out of the picture? Can you run the tests manually via the REPL?

The error is very puzzling since I've tested the inclusion of core.logic 0.8.0-rc2 with some other projects.

Comment by Timo Westkämper [ 17/Jan/13 3:31 PM ]

Here is the new stacktrace

Exception in thread "main" java.lang.IllegalArgumentException: No single method: _id of interface: clojure.core.logic.IConstraintId found for function: -id of protocol: IConstraintId, compiling:(clojure/core/logic.clj:169:5)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6566)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyze(Compiler.java:6321)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2668)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6559)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyze(Compiler.java:6321)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5707)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5138)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3750)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6557)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6547)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:528)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6559)
at clojure.lang.Compiler.analyze(Compiler.java:6360)
at clojure.lang.Compiler.analyze(Compiler.java:6321)
at clojure.lang.Compiler.eval(Compiler.java:6622)
at clojure.lang.Compiler.load(Compiler.java:7062)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.loadResourceScript(RT.java:352)
at clojure.lang.RT.load(RT.java:431)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5039.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4988.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:621)
at clojure.core$use.doInvoke(core.clj:5497)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at symbol.types$eval75$loading_4931auto___76.invoke(types.clj:9)
at symbol.types$eval75.invoke(types.clj:9)
at clojure.lang.Compiler.eval(Compiler.java:6618)
at clojure.lang.Compiler.eval(Compiler.java:6607)
at clojure.lang.Compiler.load(Compiler.java:7062)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.loadResourceScript(RT.java:352)
at clojure.lang.RT.load(RT.java:431)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5039.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4988.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$require.doInvoke(core.clj:5486)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at symbol.includes_test$eval69$loading_4931auto___70.invoke(includes_test.clj:9)
at symbol.includes_test$eval69.invoke(includes_test.clj:9)
at clojure.lang.Compiler.eval(Compiler.java:6618)
at clojure.lang.Compiler.eval(Compiler.java:6607)
at clojure.lang.Compiler.load(Compiler.java:7062)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.loadResourceScript(RT.java:352)
at clojure.lang.RT.load(RT.java:431)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5039.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4988.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$load_libs.doInvoke(core.clj:5403)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:619)
at clojure.core$require.doInvoke(core.clj:5486)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at user$eval29$fn__50.doInvoke(NO_SOURCE_FILE:1)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:617)
at user$eval29.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6618)
at clojure.lang.Compiler.eval(Compiler.java:6608)
at clojure.lang.Compiler.eval(Compiler.java:6581)
at clojure.core$eval.invoke(core.clj:2852)
at clojure.main$eval_opt.invoke(main.clj:300)
at clojure.main$initialize.invoke(main.clj:319)
at clojure.main$null_opt.invoke(main.clj:354)
at clojure.main$main$fn__6676.invoke(main.clj:432)
at clojure.main$main.doInvoke(main.clj:429)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: No single method: _id of interface: clojure.core.logic.IConstraintId found for function: -id of protocol: IConstraintId
at clojure.lang.Compiler$InvokeExpr.<init>(Compiler.java:3422)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3629)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6561)
... 99 more
Subprocess failed

Comment by Timo Westkämper [ 17/Jan/13 3:32 PM ]

Yes, same via repl

tiwe@tiwe:~/work/workspace/symbol$ lein repl
nREPL server started on port 55271
REPL-y 0.1.0-beta10
Clojure 1.5.0-RC2
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
(user/sourcery function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc]
(user/clojuredocs name-here)
(user/clojuredocs "ns-here" "name-here")
CompilerException java.lang.IllegalArgumentException: No single method: _id of interface: clojure.core.logic.IConstraintId found for function: -id of protocol: IConstraintId, compiling:(clojure/core/logic.clj:169:5)
reply.eval-modes.nrepl=>

Comment by David Nolen [ 17/Jan/13 3:41 PM ]

OK, I just cloned your repo and switched the dependencies to Clojure 1.5.0-RC2 and core.logic 0.8.0-rc2. I can run lein repl without a hitch. While it's a bit obnoxious have you tried blowing away your maven cache and trying again? Perhaps there are other changes that aren't in your master branch on GitHub?

Comment by Timo Westkämper [ 17/Jan/13 3:51 PM ]

Yes, sorry, I forgot to push some changes. Could you pull and try again?

Comment by David Nolen [ 17/Jan/13 3:55 PM ]

I still cannot reproduce after pulling from master. I note that your repl prompt looks a bit different from mine however - "reply.eval-modes.nrepl=>", whereas I have "symbol.main=>"

Comment by Timo Westkämper [ 18/Jan/13 2:41 AM ]

It looks like this was caused by a too old version of clojure on my machine. I didn't realize lein uses the clojure version I have installed on Ubuntu for compilation instead of the version mentioned in project.clj.

Comment by David Nolen [ 18/Jan/13 9:53 AM ]

Thanks for the update, closing this one!





[LOGIC-1] Tabling bug Created: 18/May/11  Updated: 28/Jul/13  Resolved: 21/May/11

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

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

Patch: Code
Approval: Ok

 Description   

Pepjin pointed out that trying to determine the path on this graph, http://paste.pocoo.org/show/391274/, does not terminate even with tabling.



 Comments   
Comment by Pepijn de Vos [ 19/May/11 6:39 AM ]

Probably related. The second run also produces 10 items, while it can produce many more, as showed in run 3 by reversing the arguments.

user=> (run 10 [q] (desto "munchen" q))
("wien" "frankfurt" "venezia" "zurich" "warszawa" "zacrab" "berlin" "munchen" "amsterdam" "budapest")
user=> (run 20 [q] (desto "munchen" q))
("wien" "frankfurt" "venezia" "zurich" "warszawa" "zacrab" "berlin" "munchen" "amsterdam" "budapest")
user=> (run 20 [q] (desto q "munchen"))
("frankfurt" "wien" "zurich" "venezia" "marseille" "paris" "barcelona" "berlin" "moskva" "athina" "kharkov" "wilno" "smyrna" "kyiv" "pamplona" "madrid" "lisboa" "warszawa" "rostov" "brindisi")

Comment by David Nolen [ 21/May/11 1:00 PM ]

Fixed by https://github.com/clojure/core.logic/commit/5a15ba9555cd349f9e3f6df786ecfc3cd231abde





[LOGIC-77] Finite-domain vars inside a vector crash when constrained. Created: 15/Dec/12  Updated: 28/Jul/13  Resolved: 24/Dec/12

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

Type: Defect Priority: Major
Reporter: Gary Fredericks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

clojure 1.5.0-beta1 with core.logic 0.8.0-beta3



 Description   

I don't know a lot about the finite domain code, but it surprised me that this crashes:

(run 1 [r a b x]
  (== r [a b])
  (infd a b x (domain 1 2))
  (<fd a b)
  (firsto r x))

This was the most minimal example I could come up with.



 Comments   
Comment by David Nolen [ 15/Dec/12 7:43 PM ]

This commit http://github.com/clojure/core.logic/commit/07f2f6ac42ad13ed7476f70669b98e76a84f2455 fixes the exception. However I'm still not seeing the expected result which I believe is:

([[1 2] 1 2 1])
Comment by David Nolen [ 15/Dec/12 9:17 PM ]

This is bug results from the trickiness of aliasing of logic vars in the presence of constraints. Currently when two constrained vars are unified, we point one var to the other var and migrate the constraints. However this is not enough we also need to merge their domains - this is not currently being done.

Comment by David Nolen [ 24/Dec/12 6:14 PM ]

fixed, http://github.com/clojure/core.logic/commit/d4d4cd53edfd76c2f416bd699f4b4d914f880985





[LOGIC-79] Setting finite domain on more than two lvars using domain fn throws UnsupportedOperationException Created: 18/Dec/12  Updated: 28/Jul/13  Resolved: 20/Dec/12

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

Type: Defect Priority: Major
Reporter: Frederik De Bleser Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure 1.4.0 , core.logic 0.8.0-beta3



 Description   

When specifying domains on more than two lvars core.logic 0.8.0-beta3 throws an UnsupportedOperationException. Here's an example:

(run* [q]
    (fresh [x y z]
        (infd x y z (domain 1 2 3))
  	    (<fd x y)
  	    (<fd y z)
        (== q [x y z])))
  • 0.8.0-beta2: nil.
  • 0.8.0-beta3: UnsupportedOperationException count not supported on this type: FiniteDomain clojure.lang.RT.countFrom (RT.java:545)
  • 0.8.0-beta4-SNAPSHOT (739ec7e): ([1 2 3]) (correct result)

I've checked and commit 07f2f6a introduced the fix, so this is possibly related to LOGIC-77.

When trying to isolate the bug I found that:

  • Using `(interval 1 3)` instead of `(domain 1 2 3)` works.
  • Using two fresh variables instead of three works:
(run* [q]
      (fresh [x y]
	      (infd x y (domain 1 2))
  	    (<fd x y)
        (== q [x y])))
;=> ([1 2])

Here's a test that checks the behavior. The test works in the latest version but fails in all commits before 07f2f6a.

(deftest test-domfd-three-lvars []
  (is (= (run* [q]
           (fresh [x y z]
           (infd x y z (domain 1 2 3))
           (<fd x y)
           (<fd y z)
           (== q [x y z])))
         '([1 2 3]))))


 Comments   
Comment by David Nolen [ 18/Dec/12 9:29 AM ]

So is there a bug in master or not? To keep tracking issues simpler, if the bug does not exist in master please don't open a ticket.

Comment by Frederik De Bleser [ 18/Dec/12 9:34 AM ]

The issue is fixed in master.

I still wanted to report it since it seems to somehow relate to LOGIC-77 – maybe I should just have added a comment there.

Sorry for the confusion.

Comment by David Nolen [ 20/Dec/12 11:51 PM ]

Not relevant to master.





[LOGIC-98] nominal unification misses after-the-fact fd constraints Created: 05/Jan/13  Updated: 28/Jul/13  Resolved: 11/Jan/13

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-98.diff     File logic-98-nominal.diff    

 Description   

Related to http://dev.clojure.org/jira/browse/LOGIC-92, these two snippets both return (nom/tie 'a_0 1) instead of three results for 1, 2, 3.

(run* [q]
  (nom/fresh [a b c]
    (fresh [x y]
      (== (nom/tie b (nom/tie a x)) (nom/tie c q))
      (infd x (interval 1 3)))))

(run* [q]
  (nom/fresh [a b c]
    (fresh [x y]
      (infd y (interval 1 3))
      (== (nom/tie b (nom/tie a x)) (nom/tie c q))
      (== x y))))


 Comments   
Comment by Nada Amin [ 08/Jan/13 4:24 AM ]

logic-98.diff fixes this by forcing all nom-related vars at once.

Do you have any ideas for separating the concern, so that force-ans doesn't need to know about ::nom?

Comment by David Nolen [ 08/Jan/13 6:32 AM ]

Will need to think about this some more.

Comment by Nada Amin [ 08/Jan/13 2:33 PM ]

Ouch! Here is a snippet that doesn't do the right thing, even with the patch:

(run* [q]
  (nom/fresh [a b c d]
    (fresh [x y z]
      (== (nom/tie b (nom/tie a x)) (nom/tie c z))
      (infd x (interval 1 3))
      (== (nom/tie d q) z))))

It returns only (1) instead of (1 2 3).

Comment by Nada Amin [ 11/Jan/13 10:07 AM ]

logic-98-nominal.diff is a solution that works for all three test cases above by simply making core.logic.nominal aware of ::fd and updating the doms when appropriate.

Comment by David Nolen [ 11/Jan/13 10:49 AM ]

fixed, http://github.com/clojure/core.logic/commit/ef27fa3ed2381f3ad4685d4bc59a298646a4febb

It would be nice if nominal didn't need to know about fd, as there will be other "enumerable" domains in the future. But this works great for now.





[LOGIC-94] nominal, spurious nil Created: 03/Jan/13  Updated: 28/Jul/13  Resolved: 03/Jan/13

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

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Nada Amin
Resolution: Declined Votes: 0
Labels: None


 Description   
(nth
    (run 2 [q]
      (nom/fresh [a0 a1]
        (redo* q `((~'fn ~(nom/tie a0 a0)) (~'fn ~(nom/tie a1 a1))))))
    1) ; => ((fn  [a_0] (quote ((fn  [a_1] a_1) (fn  [a_2] a_2)))) nil)


 Comments   
Comment by Nada Amin [ 03/Jan/13 6:51 PM ]

Oh, this is actually correct.
nil is a value in our mini-language, so this applies the first function to nil, but then doesn't use it, and just returns the requested result quoted.

Comment by Nada Amin [ 03/Jan/13 6:51 PM ]

Not a bug





[LOGIC-127] Swapping noms turns maps (and other collections) into seqs Created: 02/Apr/13  Updated: 28/Jul/13  Resolved: 10/Apr/13

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

Type: Defect Priority: Major
Reporter: Jiří Maršík Assignee: Nada Amin
Resolution: Completed Votes: 0
Labels: bug, nominal

Attachments: Text File INomSwap-vectors-maps.patch     Text File INomSwap-vectors-maps-with-test.patch    
Approval: Accepted

 Description   

When I unify two binders, the swapping procedure turns all the maps inside the body into seqs of key/value pairs, which do not unify with maps, leading to the following trickiness:

(require '[clojure.core.logic :as l])
(require '[clojure.core.logic.nominal :as n])
(l/run* [q]
  (l/fresh [body]
    (n/fresh [a b]
      (l/== (n/tie a {:k a}) (n/tie b body))
      (l/== {:k q} body))))
;=> ()
; Expected (a_0)

For my purposes, fixing this by adding two new implementations of INomSwap for vectors and maps works well.



 Comments   
Comment by Jiří Maršík [ 02/Apr/13 11:14 AM ]

Oops, sorry for the malformatted code snippet. Here it is inside a code tag.

(require '[clojure.core.logic :as l])
(require '[clojure.core.logic.nominal :as n])
(l/run* [q]
        (l/fresh [body]
                 (n/fresh [a b]
                          (l/== (n/tie a {:k a}) (n/tie b body))
                          (l/== {:k q} body))))
;=> ()
; Expected (a_0)
Comment by David Nolen [ 02/Apr/13 11:22 AM ]

This seems like a easy one to fix, perhaps Nada can see quicker than I can. If not I can take a look.

Also your patch may very well solve the issue best, feel free to attach it to the ticket. We won't be able to apply it until you've submitted your Contributor Agreement - if you have a free moment please send it in. Thanks!

Comment by Jiří Maršík [ 02/Apr/13 11:48 AM ]

The patch that I use to fix the issue. I haven't signed the CA, but I would definitely like to. Might take a while to arrive though, since I'm in Europe and I'm lazy.

Comment by Nada Amin [ 03/Apr/13 2:36 AM ]

The patch LGTM. I would also add a test from the ticket example.

I guess we have to wait until the CA arrives, now.

Comment by Jiří Maršík [ 03/Apr/13 4:28 AM ]

I have also added the test case, the new patch INomSwap-vectors-maps-with-test.patch contains both the fix and the test case. I have just signed the CA and I plan to post it today.

Comment by Jiří Maršík [ 09/Apr/13 10:55 AM ]

OK, the CA has arrived and been processed.

http://clojure.org/contributing

  • Jiri Marsik (jirkamarsik)
Comment by Nada Amin [ 10/Apr/13 3:32 AM ]

Applied as https://github.com/clojure/core.logic/commit/d73c836c0d4bab2af12b4bdedb31daad4a661fb6

Thanks!





[LOGIC-103] another non-termination case with CLP(FD) Created: 10/Jan/13  Updated: 28/Jul/13  Resolved: 10/Jan/13

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

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


 Description   
(run 2 [q]
  (fresh [a b s p]
    (infd a b (interval 2 99))
    (<=fd b a)
    (+fd a b s)
    (*fd a b p)
    (== q [a b s p])))

It's strange that we don't get the next possibility.



 Comments   
Comment by David Nolen [ 10/Jan/13 5:37 PM ]

fixed, http://github.com/clojure/core.logic/commit/e882be8dce190873431d61aefe89a025ab9c0cb6





[LOGIC-32] Unification bug Created: 15/Mar/12  Updated: 28/Jul/13  Resolved: 15/Mar/12

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

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


 Description   
(run* [q] (== q #{1}))

Results in the following exception:

IllegalArgumentException 
Don't know how to create ISeq from: 
java.lang.Long  clojure.lang.RT.seqFrom (RT.java:487)


 Comments   
Comment by David Nolen [ 15/Mar/12 6:17 PM ]

Fixed, https://github.com/clojure/core.logic/commit/a473226d0a9aeadace0a322d506c69f13c81970a





[LOGIC-108] featurec or something similar to provide recursive partial partial map constraints Created: 24/Jan/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: Enhancement Priority: Major
Reporter: Kevin Downey Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 24/Jan/13 3:58 PM ]

Basically, it should be ok for the `fs` argument to a be a nested map.

Comment by Kevin Downey [ 26/Jan/13 6:03 PM ]

the following seems to be pretty close:

    (defn rfeaturec [m f]
      (let [new-f (reduce (fn [m [k v]]
                            (assoc m k (logic/lvar (name k)))) {} (seq f))]
        (logic/fresh []
          (logic/featurec m new-f)
          (fn [s]
            (logic/to-stream
              (for [[k lvar] new-f]
                ((let [v (get f k)]
                   (if (map? v)
                     (logic/fresh [x]
                       (logic/featurec m {k lvar})
                       (rfeaturec lvar v))
                     (logic/== lvar v))) s)))))))
Comment by Kevin Downey [ 27/Jan/13 12:13 AM ]

the above falls apart quickly under use, the below works well so far:

(defn rfeaturec [m f]
  (let [new-f (reduce (fn [m [k v]] (assoc m k (logic/lvar (name k)))) {} (seq f))]
    (logic/fresh []
      (logic/featurec m new-f)
      (logic/everyg
       (fn [[k lvar]]
         (let [v (get f k)]
           (if (map? v)
             (logic/fresh []
               (logic/featurec m {k lvar})
               (rfeaturec lvar v))
             (logic/== lvar v))))
       new-f))))
Comment by David Nolen [ 27/Jan/13 6:43 PM ]

recursive featurec should work by recursively applying constraints like you've done but by using the lower level apis - we don't want to put the search language into a constraint.

Comment by David Nolen [ 17/Mar/13 7:50 PM ]

fixed, http://github.com/clojure/core.logic/commit/d5eda7d7f89443b449d7955a76e72828561082f6





[LOGIC-7] cannot emit lvars from macros Created: 01/Jun/11  Updated: 28/Jul/13  Resolved: 24/Jul/11

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

Type: Enhancement Priority: Major
Reporter: Kevin Downey Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

if we have a pattern matching macro like, for example, a cond-m that does something like
(cond-m some-value
some-pattern some-code-to-execute-on-match
some-other-pattern ...
another-pattern ...)
it would be nice if the work of preping the patterns could be done at compile time and just emit clojure literals representing the prepared patterns, lvars are currently not emittable in code, so the cost of prepping patterns would be incurred at runtime.



 Comments   
Comment by Kevin Downey [ 01/Jun/11 5:13 PM ]

this seems to turn an expression containing lvars into something you can return from a macro

(defn emittable [expr]
(postwalk
(fn [expr]
(cond
(mk/lvar? expr)
`(clojure.core.logic.minikanren.LVar.
~(.name expr)
~(.hash expr)
~(.cs expr))
(symbol? expr)
`(quote ~expr)
(seq? expr)
`(list ~@expr)
:else expr))
expr))

Comment by Kevin Downey [ 01/Jun/11 6:04 PM ]

the problem shows up with lcons as well, a possibly solution would be to have lcons and lvar and whatever else have a protocol IEmittable extended to them, where (emit some-lvar) would for example return `(LVar. ~(.name some-lvar) ~(.hash some-lvar) ~(.cs some-lvar))

Comment by David Nolen [ 24/Jul/11 1:20 PM ]

This is currently outside scope.





[LOGIC-124] Order of args to fd/!= changes results (gives incorrect answer) Created: 24/Mar/13  Updated: 28/Jul/13  Resolved: 24/Mar/13

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

Type: Defect Priority: Major
Reporter: Ryan Senior Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File arch-friends.patch    

 Description   

I have attached a failing test for the Arch Friends logic puzzle. Swapping the args to fd's != fixes the problem. So does moving the call to fd's != to after the fd's == or fd's + below it.

Tried this on 0.8.0-rc2, 0.8.0 and 0.8.1.



 Comments   
Comment by David Nolen [ 24/Mar/13 2:47 PM ]

fixed, http://github.com/clojure/core.logic/commit/ce323c9bb85e080211eddfb7203a34104c62dee3





[LOGIC-52] Bug in finite domains (+fd, infd) Created: 10/Sep/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

Type: Defect Priority: Major
Reporter: naeg Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: +fd, bug, finite-domains, infd
Environment:

Clojure 1.4, core.logic 0.8-alpha3



 Description   

When running the code:

(run* [q]
(fresh [a b c d]
(infd a b c d (domain 1 3 4 5))
(+fd b 1 a)
(+fd c 1 b)
(+fd d 1 c)
(== q [a b c d])))

I get the ouput:

([5 4 3 1])

But I would expect:

()

Because [5 4 3 1] is no sequence where the next element is always one number higher than the one before.

It seems to me like +fd behaves as it would take the next element in the domain, instead of taking the next higher number (I hope I didn't misunderstand +fd or infd).



 Comments   
Comment by naeg [ 11/Sep/12 4:48 PM ]

There is workaround using membero:

(run* [q]
  (fresh [a b c d]
    (everyg #(membero % [1 3 4 5]) [a b c d])
    (+fd b 1 a)
    (+fd c 1 b)
    (+fd d 1 c)
    (== q [a b c d])))

=> ()

Note that this is quite a lot slower than it would be with infd.

Comment by David Nolen [ 26/Oct/12 1:03 AM ]

This is fixed try the latest 0.8.0 beta





[LOGIC-58] make defrecord unification easier to adopt Created: 26/Sep/12  Updated: 28/Jul/13  Resolved: 15/Dec/12

Status: Closed
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: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 04/Oct/12 7:29 PM ]

As pointed out on the mailing list calling empty on defrecord doesn't actually make sense. defrecords are never empty in the IPersistentCollection sense, they just have their keys initialized to nil. I'm open to suggestions here.

Comment by David Nolen [ 15/Dec/12 7:19 PM ]

This was resolved a while back with the addition of the IUninitialized protocol





[LOGIC-137] OOM when setting (interval 1 2) for 20 logic vars Created: 11/May/13  Updated: 28/Jul/13  Resolved: 08/Jun/13

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

Type: Defect Priority: Major
Reporter: Gary Fredericks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

Clojure 1.5.1, both 0.8.3 and 0.8.4--994a7a3

Running on a 1GB VM.


Attachments: Text File LOGIC-137.patch    

 Description   

The following two programs (presumably equivalent) both give me OOM (heap space):

(let [vs (repeatedly 20 l/lvar)]
  (l/run 1 [q]
     (l/== q vs)
     (l/everyg (fn [v] (fd/in v (fd/interval 1 2))) vs)))
(l/run 1 [q]
         (l/fresh [x1 x2 x3 x4 x5 x6 x7 x8 x9
                   x10 x11 x12 x13 x14 x15
                   x16 x17 x18 x19 x20]
                  (l/== q [x1 x2 x3 x4 x5 x6 x7 x8 x9
                           x10 x11 x12 x13 x14 x15
                           x16 x17 x18 x19 x20])
                  (fd/in x1 x2 x3 x4 x5 x6 x7 x8 x9
                         x10 x11 x12 x13 x14 x15
                         x16 x17 x18 x19 x20
                         (fd/interval 1 2))))

I assume the expected value is something like ([1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1]).



 Comments   
Comment by David Nolen [ 31/May/13 11:49 AM ]

We got another report about this issue. Consider:

(let [vs (into [] (take 17 (repeatedly lvar)))]
  (doall
    (run 1 [q]
      (== q vs)
      (everyg #(fd/in % (fd/interval 60 69)) vs))))

The behavior seems exponential in N, currently here at 17, but on my Macbook Air going to 20 results in hanging my REPL.

Comment by Gary Fredericks [ 05/Jun/13 7:51 PM ]

It looks like this has nothing to do with domains actually. I get the same effect with the following:

(let [vs (repeatedly 16 lvar)]
  (run 1 [q]
       (everyg #(conde [(== % 1)] [(== % 2)]) vs)
       (== q vs)))
Comment by David Nolen [ 05/Jun/13 8:09 PM ]

Thanks for the extra details!

Comment by Gary Fredericks [ 07/Jun/13 10:53 PM ]

In hindsight this seems obvious.

I think it must follow directly from the breadth-first-search approach ensured by conde's interleaving.

If the expression in my previous comment creates a binary tree of depth 16, and the single answer we want is in the leftmost leaf, we still can't get to that leaf before searching through the entire tree (breadth first), which means having the whole thing in memory in some sense, which means OOM whenever the tree isn't too small.

I assume this is a fundamentally difficult problem. Should this still be considered a bug?

Comment by David Nolen [ 08/Jun/13 1:51 PM ]

`conde` isn't bread-first, it's interleaving. I will need to think about it some more. I'm mostly concerned with the FD case because we rely on `map-sum` which uses `conde`, perhaps there's something clever we can do for domain enumeration?

Comment by Gary Fredericks [ 08/Jun/13 2:53 PM ]

One thing that seems to clear up the issue but which could easily have subtle performance issues I don't understand is removing the -inc from conde. This clears up all the test cases given here, and the test suite still passes.

I don't think the -inc is necessary in the cases where we know that the goals are simple ones (like unification) that don't diverge. So another approach is to have a special goal for disjunctively unifying with a bunch of concrete values:

(defn ==any
  "Like membero, but requires that vals be a ground sequence, and probably                                                                                                                     
   performs better."
  [x vals]
  (fn [s]
    (if-let [[v & vs] (seq vals)]
      (choice (unify s x v)
              (fn []
                ((==any x vs) s))))))

Using this (like you would membero) instead of conde seems to clear it up, and could presumably be used instead of conde in map-sum.

What do you think? Is there anything in particular that should be investigated regarding this approach?

Comment by Gary Fredericks [ 08/Jun/13 3:05 PM ]

I just looked at the code that uses map-sum closer and realized I don't understand everything that's going on, so am not totally sure if/how ==any would fit there.

Comment by Gary Fredericks [ 08/Jun/13 3:28 PM ]

In playing around with it I realized the definition of ==any should not use choice directly but rather mplus, which should still have the same performance gain.

Then I was able to use the same technique inlined with map-sum, which gives:

(defn map-sum [f]
  (fn loop [ls]
    (if (empty? ls)
      (fn [a] nil)
      (fn [a]
        (mplus
         ((f (first ls)) a)
         (fn []
           ((loop (rest ls)) a)))))))

The tests pass, and the FD examples are fast.

I started a branch here: https://github.com/fredericksgary/core.logic/compare/LOGIC-137

Comment by David Nolen [ 08/Jun/13 5:21 PM ]

Please attach a patch with the `map-sum` improvement. Thanks!

Comment by Gary Fredericks [ 08/Jun/13 6:03 PM ]

Attached patch with the altered map-sum.

Comment by David Nolen [ 08/Jun/13 8:30 PM ]

fixed http://github.com/clojure/core.logic/commit/5afeace2761eeb6731cf558bed354607e5401631





[LOGIC-72] Unification with partial-map fails when a map contains a map value with extra keys Created: 22/Nov/12  Updated: 28/Jul/13  Resolved: 23/Nov/12

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

Type: Defect Priority: Major
Reporter: Hugo Duncan Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: None

Attachments: File recursive-partial-map.diff    
Patch: Code and Test

 Description   

Unification fails for partial-map when there is a partial match on a sub-map.

A failing test case:

(is (= '[#clojure.core.logic.PMap{:a {:b 2}}]
         (run* [q]
           (fresh [pm x]
             (== (partial-map {:a {:b x}}) pm)
             (== {:a {:b 2 :c 3}} pm)
             (== q pm)))))


 Comments   
Comment by Hugo Duncan [ 23/Nov/12 3:55 PM ]

As mentioned by Kevin Lynagh, this can be achieved using walk-term, and I agree the behaviour is better off being explicit.

(defn ->pmap [x]
  (if (map? x)
    (l/partial-map x)
    x))

(l/unifier target (->pmap (l/walk-term my-map ->pmap)))
Comment by David Nolen [ 23/Nov/12 3:58 PM ]

having partial-map implicitly recurse is undesirable. It's easy to achieve the desired behavior now that we have a reusable walk-term built into core.logic.





[LOGIC-59] tabled goals should have tables local to a particular run Created: 17/Oct/12  Updated: 28/Jul/13  Resolved: 28/Dec/12

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

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


 Description   

Currently tabled goals cannot be used across multiple runs which is simply awful.



 Comments   
Comment by David Nolen [ 28/Dec/12 8:35 PM ]

fixed, http://github.com/clojure/core.logic/commit/ef437d676e72dd9a30e60b31d8ee4a1dccbfdcef





[LOGIC-55] Unification of sets allows for duplicate values leading to non-set-like behavior Created: 21/Sep/12  Updated: 28/Jul/13  Resolved: 27/Sep/12

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

Type: Defect Priority: Major
Reporter: Aaron Brooks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Considering this behavior:

user> (run* [out] (== 3 out) (== #{3 out} #{3 out}))
(3)

There are other more convoluted cases involving multiple lvars but I think the above is enough for discussion. I think the above behavior is at least unexpected (desiring documentation) if not actually incorrect behavior.

A possible solution would be to apply distincto (or some equivalent) to the members of each incoming set before the body of unify-with-set (extending IUnifyWithSet to clojure.lang.IPersistentSet). Naturally this makes set unification even more expensive than it currently is but I'm currently inclined to think that this additional cost is unavoidable, at least with the current approach.



 Comments   
Comment by David Nolen [ 21/Sep/12 3:19 PM ]

I probably should held off on implementing unification with sets. Oh well. The distincto approach sounds reasonable to me - would gladly take a patch.

Comment by Aaron Brooks [ 21/Sep/12 3:22 PM ]

I'll look in to that. Would you be against declaring distincto so I can use it earlier in the file? I don't recall off the top of my head but I think distincto can't be moved that early in the file and probably wants to stay where it is anyways.

Comment by David Nolen [ 27/Sep/12 9:38 PM ]

fixed, http://github.com/clojure/core.logic/commit/cdc4bf8563e9f566cc6e3e0e4f8a7735cd92b88e





[LOGIC-104] -merge-doms for ::nom is not closed under composition Created: 11/Jan/13  Updated: 28/Jul/13  Resolved: 11/Jan/13

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-104.diff    

 Description   
(run* [q]
  (nom/fresh [a b c d]
    (fresh [x y z]
      (== (nom/tie a (nom/tie b y)) (nom/tie b (nom/tie a x)))
      (== (nom/tie c (nom/tie d x)) (nom/tie d (nom/tie c z)))
      (== x y)
      (== z x))))

The snippet above fails with a no implementation of method -merge-doms for LazySeq, because -merge-doms for ::nom is implemented for vectors but returns a lazy seq, not a vector.

The simplest fix is to change `concat` to `into` in the -merge-doms implementation of nominal.clj. However, while I am at it, I will replace the vector with a set, which makes more sense given how it's used anyways.

Patch will be attached shortly.



 Comments   
Comment by Nada Amin [ 11/Jan/13 7:59 AM ]

Patch logic-104.diff contains improved ::nom dom representation and test for this bug.

Comment by David Nolen [ 11/Jan/13 8:35 AM ]

fixed, http://github.com/clojure/core.logic/commit/9f0f0c70b9d02cabe7ac1dd0d10106d84e7c3870





[LOGIC-54] Set unification does not operate symmetrically Created: 21/Sep/12  Updated: 28/Jul/13  Resolved: 27/Sep/12

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

Type: Defect Priority: Major
Reporter: Aaron Brooks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Fix-unify-with-set-to-work-symmetrically.patch    
Patch: Code and Test

 Description   

A check is absent in unify-with-set that would check for missing values in addition to missing lvars. The incorrect behavior is shown below:

user> (run* [out] (== #{out} #{1}))
(1)
user> (run* [out] (== #{1} #{out}))
()

The attached patch includes a similar test to the above and was run against the HEAD as of this posting.



 Comments   
Comment by David Nolen [ 21/Sep/12 2:58 PM ]

Thanks for the report will look into it.

Comment by David Nolen [ 27/Sep/12 9:38 PM ]

fixed, http://github.com/clojure/core.logic/commit/cdc4bf8563e9f566cc6e3e0e4f8a7735cd92b88e





[LOGIC-9] make run non-lazy, add lazy-run variant Created: 08/Jun/11  Updated: 28/Jul/13  Resolved: 08/Jun/11

Status: Closed
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: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

The laziness of the run interface is not essential to core.logic's operation. lazy-sequences are used in core.logic simply as a way to get TCO like behavior / prevent stack overflow. run being non-lazy makes tabling goals only for the duration of a run much simpler to implement.



 Comments   
Comment by David Nolen [ 08/Jun/11 10:42 PM ]

Fixed by 1c9610ba6d51837b14854e015f5e7a1ce37e65a2





[LOGIC-11] Disequality Constraints - lvar remains fresh if we have disequality constraint that involves lcons Created: 14/Jul/11  Updated: 28/Jul/13  Resolved: 24/Jul/11

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

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


 Description   

(run* [q]
(exist [x a b]
(!= x (lcons a b))
(== x 1)))

;; (_.0)



 Comments   
Comment by David Nolen [ 24/Jul/11 1:09 PM ]

the behavior is correct.





[LOGIC-76] partial-maps break the transitivity of unification Created: 14/Dec/12  Updated: 28/Jul/13  Resolved: 28/Dec/12

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

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


 Description   

partial-map should never unify with fresh vars - this should be a hard error. This means partial-map functionality needs to be accessible by some other means - probably a constraint - `featurec` might be a good name for it. This way partial-maps never leak into an actual program, and users don't try to make the concrete data structure participate in unification. At the same time this does allow extracting features of interest via unification once the term (map) being checked actually becomes ground.



 Comments   
Comment by David Nolen [ 28/Dec/12 12:42 AM ]

resolved in master, functionality now available via `featurec`





[LOGIC-92] nominal is missing a few constraints-related tweaks Created: 02/Jan/13  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: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File nominal-infd.diff    

 Description   

These tests fail. We get only the first result.

(is (= (run* [q]
           (fresh [x]
             (nom/fresh [a]
               (infd x (interval 1 3))
               (== q (nom/tie a x)))))
        [(nom/tie 'a_0 1) (nom/tie 'a_0 2) (nom/tie 'a_0 3)]))
  (is (= (run* [q]
           (nom/fresh [a b c]
             (fresh [x]
               (infd x (interval 1 3))
               (== (nom/tie b (nom/tie a x)) (nom/tie c q)))))
        [(nom/tie 'a_0 1) (nom/tie 'a_0 2) (nom/tie 'a_0 3)]))


 Comments   
Comment by Nada Amin [ 02/Jan/13 9:09 AM ]

nominal-infd.diff contains fix and tests.

Comment by David Nolen [ 02/Jan/13 9:17 AM ]

fixed, http://github.com/clojure/core.logic/commit/f973b36cb02b3b797852859f2cc2a09356157cc4





[LOGIC-73] Usage of c.c.l/prep can lead to a different result (compared to not using it) Created: 23/Nov/12  Updated: 28/Jul/13  Resolved: 23/Nov/12

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

Type: Defect Priority: Major
Reporter: Hugo Duncan Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Below are two expressions that differ only in the use of c.c.l/prep. When using prep there is an extra term returned, that includes a free ?a, which seems wrong, considering the second pattern should unify on the :a key.

(let [rules
      [{:pattern (partial-map (prep {:a :clojure.core.logic/not-found :x 1}))
        :production (prep {:a 1})}
       {:pattern (partial-map (prep {:a '?a :c :clojure.core.logic/not-found}))
        :production (prep {:c '(* ?a 2)})}]]
  (run* [q]
    (fresh [pattern production guards rule rule-name]
      (membero {:pattern pattern :production production} rules)
      (== {:x 1}  pattern)
      (== q production))))
  => ({:a 1} {:c (* _.0 2)})
(let [rules
      [{:pattern (partial-map {:a :clojure.core.logic/not-found :x 1})
        :production {:a 1}}
       {:pattern (partial-map {:a '?a :c :clojure.core.logic/not-found})
        :production {:c '(* ?a 2)}}]]
  (run* [q]
    (fresh [pattern production guards rule rule-name]
      (membero {:pattern pattern :production production} rules)
      (== {:x 1}  pattern)
      (== q production))))
  => ({:a 1})


 Comments   
Comment by David Nolen [ 23/Nov/12 4:34 PM ]

fixed, http://github.com/clojure/core.logic/commit/9a964d6c744433825332dd82370cb46eac7919da

Comment by Hugo Duncan [ 23/Nov/12 10:03 PM ]

The code in the prep case above contains a bug. Both the pattern and production should both be passed in a single call to prep, otherwise they end up with different logic vars. When corrected there is only one term returned when using prep.

I'm not sure what this means for the necessity or correctness of the fix.





[LOGIC-31] unifier is not commutative Created: 14/Mar/12  Updated: 28/Jul/13  Resolved: 17/Mar/12

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

Type: Defect Priority: Major
Reporter: Jens Bendisposto Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

clojure 1.3.0, core.logic 0.6.7



 Description   

I am not sure if this is actually a bug

user=> (require '[clojure.core.logic :as logic])
nil
user=> (logic/unifier (logic/unifier '{:a ?x} '{:a ?y}) '{:a 5})
nil
user=> (logic/unifier (logic/unifier '{:a ?x} '{:a 5}) '{:a ?y})
{:a 5}

For comparison: here is the result of core.unify (and what I expected)

user=> (require '[clojure.core.unify :as unify])
nil
user=> (unify/unifier (unify/unifier '{:a ?x} '{:a ?y}) '{:a 5})
{:a 5}
user=> (unify/unifier (unify/unifier '{:a ?x} '{:a 5}) '{:a ?y})
{:a 5}



 Comments   
Comment by Jens Bendisposto [ 14/Mar/12 2:58 AM ]

Obviously i meant associative, not commutative.

Comment by David Nolen [ 14/Mar/12 12:30 PM ]

Thanks for pointing this out. Yes the unifier isn't doing the right thing here. Will look into a fix.

Comment by Brian Goslinga [ 17/Mar/12 12:50 PM ]

The issue occurs because (unifier '{:a ?x} '{:a ?y}) is {:a _.0}, and since _.0 is a symbol, it does not unify with 5.

Changing the definition of solve to use walk* instead of -reify fixes the issue, but is a breaking change (and breaks tests that depend on the reification lvars).

unifier could use an alternative implementation of solve, but that probably isn't ideal and would still be a breaking change (although less of one perhaps).

Comment by David Nolen [ 17/Mar/12 2:15 PM ]

Fixed, https://github.com/clojure/core.logic/commit/468df05f4d6241cb7f30c16306631c49f391e98c





[LOGIC-57] poor performance when using tabling Created: 26/Sep/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

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

Attachments: File tabling.clj    

 Comments   
Comment by David Nolen [ 05/Oct/12 6:49 PM ]

The following commit http://github.com/clojure/core.logic/commit/03ad0a425c5b3b91a00142ff91e5fcd378daa682, should give a very big performance boost. The table still ends up storing a lot of redundant information, we could probably get another large boost by figuring out some way to share information when goals are recursive.





[LOGIC-122] Subpattern {?x (?y ?y)} fails to unify Created: 15/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: Jonas Enlund Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File LOGIC-120-121-122-squashed.diff     File LOGIC-122.diff    

 Description   

This expression should unify but doesn't:

(unify {:as '{?x (?y ?y)}} '[[?y ?x] [1 (1 1)]])


 Comments   
Comment by Jonas Enlund [ 16/Mar/13 2:35 AM ]

The patch LOGIC-122.diff includes patches for LOGIC-120 and LOGIC-121

Comment by David Nolen [ 16/Mar/13 9:18 AM ]

So unless I'm mistaken I only need to apply this patch to address the three tickets correct?

Comment by Jonas Enlund [ 16/Mar/13 9:56 AM ]

Correct. This patch fixes LOGIC-120 121 and 122. The patch for LOGIC-118 is not included in these commits. Do you want tests in a seperate ticket/patch?

Comment by David Nolen [ 16/Mar/13 10:50 AM ]

I would actually prefer a squashed patch that includes the tests. Thanks. It makes sense to deal with LOGIC-118 separately, can we make sure we have tests there as well? Thanks!

Comment by Jonas Enlund [ 16/Mar/13 11:07 AM ]

Use LOGIC-120-121-122-squashed.diff. It includes the tests.

Comment by David Nolen [ 17/Mar/13 11:39 AM ]

fixed http://github.com/clojure/core.logic/commit/2bf23fd1ea64966bae094c9f634dfb21ddd386d1





[LOGIC-21] Remove ?x variable pattern Created: 17/Nov/11  Updated: 28/Jul/13  Resolved: 27/Nov/11

Status: Closed
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: Completed Votes: 0
Labels: None


 Description   

?x is a bit noisy. We should just allow defining logic vars via match with any symbol. We can use &env to figure out if the user is referring to existing locals or not.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 24/Nov/11 7:50 AM ]

This is just referring to variables introduced with matche right?

Comment by David Nolen [ 24/Nov/11 9:54 AM ]

Yeah. At the time when I wrote those macros I hadn't used &env much.

Comment by David Nolen [ 27/Nov/11 10:55 PM ]

Fixed, https://github.com/clojure/core.logic/commit/b1ab2dbde8fa9a6332268c1810f586516baedf15





[LOGIC-39] core.logic is inconsistent in how it handles nil and false Created: 17/May/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

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


 Description   

Unification failure should always return nil. The fact that we sometimes return false and sometimes return nil creates problems when providing lower level data sources.



 Comments   
Comment by David Nolen [ 26/Oct/12 1:07 AM ]

This was resolved on the way to 0.8.0 alphas/beta





[LOGIC-106] cannot use fresh/conde in the invoke of a constraint Created: 20/Jan/13  Updated: 28/Jul/13  Resolved: 21/Jan/13

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

This means that we cannot really emulate modes with constraints. The problem is related to -inc.

An easy way to try it out is to have a dummy fresh goal in predc and see the failing tests.

@@ -2932,7 +2932,7 @@
        (invoke [this a]
          (let [x (walk a x)]
            (when (p x)
-             ((remcg this) a))))
+             (bind* a (fresh [y] (== x x)) (remcg this)))))
        IConstraintOp
        (rator [_] (if (seq? pform)
                     `(predc ~pform)


 Comments   
Comment by David Nolen [ 20/Jan/13 7:55 PM ]

Sorry I didn't mean to suggest this approach. In general you cannot put search related operators into a constraint. In fact I think we should replace any instances of bind* and bind in constraint logic as they really are a part of the search infrastructure and I'd like them to become implementation details of a particular search approach.

Instead I meant to suggest that the disjunction expressed by your example

(run 1 [re]
  (forall [s o]
    (conde
      [(== s '(foo bar bar bar))
       (== o regex-BLANK)]
      [(!= s '(foo bar bar bar))
       (== o regex-NULL)])
    (regex-matcho re s o)))

Is perhaps best described as an explicit constraint something more like:

(defn regexc [s o]
  (reify
    IFn
    (invoke [c a]
      (let [s (walk* a)[
        (if (= s '(foo bar bar bar))
          ((== o regex-BLANK) a)
          ((== o regex-NULL) a)))))
    ...
    IRunnable
    (runnable? [c a]
      (ground-terms? x))
    ...))

Of course someone might want to write constraint like this quite often, then I think it's question of what the best way to support that might be.

Comment by David Nolen [ 21/Jan/13 11:56 AM ]

No plans to add support for search operators in constraints in the near future.





[LOGIC-97] disequality pruning Created: 04/Jan/13  Updated: 28/Jul/13  Resolved: 04/Jan/13

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File diseq-pruning.diff    

 Description   

Why we need disequality pruning in updatec:

(run* [q]
           (fresh [x y z]
             (!= x [y])
             (== x [z])
             (== y 'foo)
             (== z 'bar)))

Instead of returning just '(_0), this snippet returns '((_0 :- (!= ([bar] [foo])))).



 Comments   
Comment by Nada Amin [ 04/Jan/13 1:02 PM ]

Patch diseq-pruning.diff gives up on using updatec in favor of correctness. Test case incuded.

Comment by David Nolen [ 04/Jan/13 1:13 PM ]

fixed, http://github.com/clojure/core.logic/commit/0beb770dc0a072f0dcb888f0df2978a5632d92bf





[LOGIC-18] clojure.core.logic namespace instead of clojure.core.logic.minikanren + prelude Created: 09/Oct/11  Updated: 28/Jul/13  Resolved: 20/Nov/11

Status: Closed
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: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 20/Nov/11 3:14 PM ]

done





[LOGIC-63] Prep's use of metadata needs to be extended to other objects in ClojureScript Created: 26/Oct/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

Type: Defect Priority: Major
Reporter: Paul deGrandis Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

The simple unifier and binding-map work great in the simple cases, but fail with more complicated unification.
The root cause is prep's use of metadata banging up against JS Objects.

For the cases that fail, see the current failing tests:
https://github.com/clojure/core.logic/blob/master/src/test/cljs/cljs/core/logic/tests.cljs#L871



 Comments   
Comment by David Nolen [ 26/Oct/12 12:42 PM ]

I still don't understand. Is it failing because it's trying to add metadata to objects which don't support that? That doesn't really make sense given the unifications that are failing that you've highlighted.

Comment by Paul deGrandis [ 26/Oct/12 12:55 PM ]

That's correct - I couldn't determine what the Object was in the code. Whatever it is, it just needs the IWithMeta protocol extended to it.

I thought you might have more insight.

Comment by David Nolen [ 26/Oct/12 12:58 PM ]

Ok will look into it.

Comment by David Nolen [ 26/Oct/12 5:53 PM ]

fixed http://github.com/clojure/core.logic/commit/371c0355f51ee35c6e71616ec2923a8242d6e4b3





[LOGIC-134] Historic artifacts in the implementation of Choice prevent take* from being generally usable. Created: 07/May/13  Updated: 28/Jul/13  Resolved: 07/May/13

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

Type: Defect Priority: Major
Reporter: Austin Haas Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File LOGIC-134-fix.diff    
Patch: Code

 Description   

The implementation of Choice is slightly broken, because in certain contexts it is assumed that the first value in the Choice stream will be wrapped in a list. I believe this is a historical artifact; maybe the list wrapper was used to differentiate two types of values, as in the case of distinguishing not-found from nil.

This defect prevents take* from being used generally, since the current implementation of take* for Choice assumes the first value is wrapped in a list, which is not the case for Choice streams during the search.

Patch to follow.



 Comments   
Comment by Austin Haas [ 07/May/13 3:23 PM ]

Never wrap first item to Choice in a list. Fixes LOGIC-134.

http://dev.clojure.org/jira/browse/LOGIC-134

Comment by David Nolen [ 07/May/13 10:27 PM ]

The attached patch does not work, many tests fail.

Comment by David Nolen [ 07/May/13 11:37 PM ]

fixed, http://github.com/clojure/core.logic/commit/0a8b619880c7cbea4cf8e9a280cbd5bdb413a12c





[LOGIC-69] prep does not properly recurse terms Created: 19/Nov/12  Updated: 28/Jul/13  Resolved: 21/Nov/12

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

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

Attachments: Text File logic69.patch     Text File logic69.patch    
Patch: Code and Test

 Description   
(prep {:a {:b ?c} :d ?d})

?c is not walked according to Kevin Lynagh. This should also handle complex map keys.



 Comments   
Comment by Kevin Lynagh [ 21/Nov/12 12:09 AM ]

Also available here: https://github.com/lynaghk/core.logic/tree/walk-recursive

Comment by Kevin Lynagh [ 21/Nov/12 12:13 AM ]

This patch adds prewalk recursion to IWalkTerm for map/record keys and values, seqs, and vectors.
Note that logic vars within map keys isn't going to unify in the current implementation, and probably isn't a sensible thing to do anyway. Prewalk of map keys is just so that people can use core.logic's walk implementation over clojure.walk to use the IUninitialized protocol.

Comment by Kevin Lynagh [ 21/Nov/12 12:17 AM ]

(Patch updated to walk map keys. I couldn't figure out how to remove old patch in JIRA.)

Comment by David Nolen [ 21/Nov/12 8:57 AM ]

fixed, http://github.com/clojure/core.logic/commit/bd65104ec3fda79790655d4be8a9be436f2c0d54





[LOGIC-56] Unification of sets does not consider all possibilities Created: 21/Sep/12  Updated: 28/Jul/13  Resolved: 27/Sep/12

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

Type: Defect Priority: Major
Reporter: Aaron Brooks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

The current unify-with-set logic will unify the first lvars it comes across, preventing backtrack unification with other lvars in the sets. See examples:

user> (run* [out]
        (fresh [a b c d]
          (== out [a b c d])
          (== #{a b} #{c d})))
([_.0 _.1 _.0 _.1])

user> (run* [out]
        (fresh [a b c d]
          (== out [a b c d])
          (== [a c] [7 9])
          (== #{a b} #{c d})))
()

I'm still thinking of a way to efficiently handle this but wanted to post it when I came across it.



 Comments   
Comment by Aaron Brooks [ 21/Sep/12 3:18 PM ]

BTW, I should note that issue was noticed by Jim Duey.

Comment by David Nolen [ 21/Sep/12 3:28 PM ]

More evidence that I probably should not have attempted unification with sets. This is why there is no support for logic vars as keys in maps - we should probably even throw in that case.

Perhaps we can support backtracking by switching complex unification of sets to a conde? Though at that point you're probably better of using lists + distincto.

Comment by Aaron Brooks [ 21/Sep/12 3:34 PM ]

Yeah, I looked at map unification and decided to punt entirely. One thing at a time.

Now is a good time to thank you, again, for core.logic. This is better to have than not.

Comment by David Nolen [ 26/Sep/12 3:22 PM ]

After some discussion with William Byrd at StrangeLoop I'm inclined to remove set unification from core.logic entirely. It turns out this is an open research problem and I find it unlikely that I'll be able to figure this one out anytime soon. Will this cause too much trouble for you all?

Note that a related change would be to throw on any maps that have logic vars as keys during unification.

Comment by Aaron Brooks [ 26/Sep/12 8:58 PM ]

This seems entirely reasonable. The complexity explodes quickly and distincto judiciously applied is far more efficient. Kill it as you wish. (Though I might suggest leaving the protocol in with no implementation so experimenters can easily extend it.)

Thanks!

Comment by David Nolen [ 27/Sep/12 9:36 AM ]

Excellent. I'll leave the protocol in, along with some fair warning about attempting it Thanks for the quick feedback.

Comment by David Nolen [ 27/Sep/12 9:39 PM ]

fixed, http://github.com/clojure/core.logic/commit/cdc4bf8563e9f566cc6e3e0e4f8a7735cd92b88e





[LOGIC-60] Simple unification and partial-map support for ClojureScript Created: 25/Oct/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

Type: Enhancement Priority: Major
Reporter: Paul deGrandis Assignee: Paul deGrandis
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-60-simple-unification-partmap-2.diff     File logic-60-simple-unification-partmap-3.diff     File logic-60-simple-unification-partmap.diff    

 Description   

This ports over the simple unifier (and prep and binding-map) as well as the partial-map support into ClojureScript. Additionally some deprecated protocol use was patched up.



 Comments   
Comment by David Nolen [ 25/Oct/12 11:11 AM ]

This looks great but could we copy over the related tests for simple unification and partial map unification? You can run these with script/test. Thanks.

Comment by Paul deGrandis [ 25/Oct/12 12:39 PM ]

I promise to write tests from now on

I patched up one bug, noted the failing unification for partial-map (I will open a new ticket for it).

Also, prep is failing on some JS Object because of a with-meta call. See the tests for the cases where that happens. I couldn't figure it out, but I haven't hit this in my project code (I'm doing extremely simple unification and binding-map stuff).
I'll open up a new ticket for that as well.

===
edit: take version 3 - removed print statements I left in the test file

Comment by David Nolen [ 26/Oct/12 12:40 AM ]

fixed, http://github.com/clojure/core.logic/commit/e33668ff0bd76aded94b7911e498c62473e47a6f





[LOGIC-37] The facts and retractions functions do not take the relation's namespace into account when resolving the index. Created: 03/May/12  Updated: 28/Jul/13  Resolved: 27/Sep/12

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

Type: Defect Priority: Major
Reporter: David Edgar Liebke Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Fixed-issue-resolving-the-clojure.core.logic.Rel-ind.patch    
Patch: Code

 Description   

Inserting facts into a relation that is defined in another namespace, specifically a namespace that has been required but not referred (I don't see the bug if I :use the other namespace).

I've tracked the problem down to this line:

https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1621

In the facts function, when the relation index gets resolved, the namespace is not taken into account,

index (var-get (resolve (index-sym (.name rel) arity o)))

as it is when resolving the relation set.

rel-set (var-get (ns-resolve rel-ns (set-sym (.name rel) arity)))

Using ns-resolve, with rel-ns, seems to fix the issue for me.

index (var-get (ns-resolve rel-ns (index-sym (.name rel) arity o)))



 Comments   
Comment by David Nolen [ 27/Sep/12 9:42 PM ]

Apologies for the slow response. Is this still a problem?

Comment by David Edgar Liebke [ 27/Sep/12 9:50 PM ]

Hi David,

Nope, the problem has been resolved, as I recall you applied the patch and cut a new release the same day I submitted the request; so thanks again for the quick fix!

David

Comment by David Nolen [ 27/Sep/12 9:52 PM ]

fixed





[LOGIC-132] "PMap is non-storable" exception when using featurec with nested feature map. Created: 26/Apr/13  Updated: 28/Jul/13  Resolved: 05/May/13

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

Type: Defect Priority: Major
Reporter: Martin Forsgren Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

core.locic 0.8.3



 Description   

This works as expected:

(run* [x y]
  (featurec x {:a {:b 1}})
  (== y {:b 1})
  (== x {:a y}))

;; => ([{:a {:b 1}} {:b 1}])

But with the last two goals swapped an exception is thrown:

(run* [x y]
  (featurec x {:a {:b 1}})
  (== x {:a y})
  (== y {:b 1}))

;; =>
Exception clojure.core.logic.PMap@3c6f0bed is non-storable
    clojure.core.logic.LVar (logic.clj:647)
    clojure.core.logic/unify (logic.clj:231)
    clojure.core.logic/unify-with-pmap* (logic.clj:2601)
    clojure.core.logic.PMap (logic.clj:2614)
    clojure.core.logic/unify (logic.clj:232)
    clojure.core.logic/==/fn--2819 (logic.clj:1135)
    clojure.core.logic/composeg/fn--2745 (logic.clj:1029)
    clojure.core.logic/-featurec/reify--3655 (logic.clj:2646)
    clojure.core.logic/composeg/fn--2745 (logic.clj:1029)
    clojure.core.logic/composeg/fn--2745 (logic.clj:1030)
    clojure.core.logic/run-constraint/fn--3431 (logic.clj:2184)
    clojure.core.logic/fix-constraints (logic.clj:2211)

The same exception is thrown when (== y {:b 1}) is left out:

(run* [x y]
  (featurec x {:a {:b 1}})
  (== x {:a y}))


 Comments   
Comment by David Nolen [ 05/May/13 7:34 PM ]

fixed, http://github.com/clojure/core.logic/commit/30fcd69dd4c9ca86b3a73c3f6b5866d6b943ddff





[LOGIC-113] A conde clause that beings with a fresh expression will initially fail Created: 13/Feb/13  Updated: 28/Jul/13  Resolved: 15/Feb/13

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

Type: Defect Priority: Major
Reporter: Austin Haas Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: None
Environment:

tested against HEAD (0.8.0-rc3-SNAPSHOT) and CLJ 1.5.0-RC15



 Description   
(ns test                                                                                                                                                                          
  (:refer-clojure :exclude [==])                                                                                                                                                  
  (:require                                                                                                                                                                       
   [clojure.core.logic :refer :all]))                                                                                                                                             

;; This expression should evaluate to true, but it does not, 
;; because the second run* returns (2 1) instead of (1 2).
                                                                                                                                                                                  
(= (run* [q]                                                                                                                                                                      
     (conde                                                                                                                                                                       
       [(== q 1)]                                                                                                                                                                 
       [(== q 2)]))                                                                                                                                                               
   (run* [q]                                                                                                                                                                      
     (conde                                                                                                                                                                       
       [(fresh [a] (== q 1))]                                                                                                                                                     
       [(== q 2)])))


 Comments   
Comment by David Nolen [ 14/Feb/13 12:13 AM ]

This is not an error. No promises are made about the order of results. If you want need to verify that two runs are the same it's best to put the results into a set - we actually do this in the tests now.

Comment by Austin Haas [ 14/Feb/13 1:14 AM ]

Shouldn't the programmer be able to reason about the order that the clauses will be tried? That's one way to direct the search and I know at least one example in TRS highlights that aspect--in Ch. 5, unwrapo is re-written to push the recursive call down, otherwise it diverges. How could you know that goal will terminate if you can't reason about the order of the clauses? I assume it is much more difficult to write exclusively non-overlapping clauses.

Likewise, shouldn't the programmer be able to design a logic program so that it produces a predictable first result?

This is all very new to me, so please forgive me if I'm way off.

Comment by David Nolen [ 14/Feb/13 8:57 AM ]

miniKanren makes no promises about order anymore, Will actually talks about this in his dissertation. It's part of the design and leaves the door wide open for concurrent search when we get there.

Even so, I do understand there are cases where the programmer might want more control than is provided by the default behavior. Customizable search is on the roadmap.

But the current default behavior is expected and unlikely to change.

Comment by David Nolen [ 15/Feb/13 12:49 PM ]

Not a bug.





[LOGIC-24] Suspected Regression from 0.6.5-0.6.6 Created: 23/Dec/11  Updated: 28/Jul/13  Resolved: 10/Jan/12

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

Type: Defect Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: Ambrose Bonnaire-Sergeant
Resolution: Completed Votes: 0
Labels: None


 Description   

Outlined here: http://stackoverflow.com/questions/8568894/why-run-does-not-work-with-natural-number-in-core-logic



 Comments   
Comment by David Nolen [ 10/Jan/12 9:35 PM ]

Fixed, https://github.com/clojure/core.logic/commit/2e4bd26201b197e93dc1818d1ee087645e44bb69





[LOGIC-125] Using membero with a vector as an element Created: 25/Mar/13  Updated: 28/Jul/13  Resolved: 25/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: None


 Description   

Running this code gives an unexpected result of only one of the 2 members being present:

(defn solve1 [q]
  (symbol-macrolet   [_ (lvar)]
          (membero [_ _ 'blue-cheese 'Fortune] q) ;; 2
          (membero [:5:00 _ 'mozzarella _] q) ;; 11
          ))

(run 1 [q] (solve1 q))
=> (([:5:00 _0 mozzarella _1] . _2))

While adding an empty fresh seems to resolve the problem:

(defn solve2 [q]
  (symbol-macrolet   [_ (lvar)]
   (fresh []
          (membero [_ _ 'blue-cheese 'Fortune] q) ;; 2
          (membero [:5:00 _ 'mozzarella _] q) ;; 11
        )))

(run 1 [q] (solve2 q))
=> (([_0 _1 blue-cheese Fortune] [:5:00 _2 mozzarella _3] . _4))


 Comments   
Comment by David Nolen [ 25/Mar/13 10:52 AM ]

This is not a bug. You must always wrap a conjunction of goals in a run, fresh or an all or some other compound goal construct built from these primitives.

Comment by Matthew O. Smith [ 25/Mar/13 11:31 AM ]

Thanks, that is good to know.





[LOGIC-112] Incorrect results with tabled resolution Created: 05/Feb/13  Updated: 28/Jul/13  Resolved: 13/Mar/13

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

Type: Defect Priority: Major
Reporter: Reinout Stevens Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

org.clojure/clojure "1.3.0"
org.clojure/core.logic "0.8.0-rc2"


Attachments: File tabling-test.clj    
Patch: Code

 Description   

We (authors of damp.qwal and damp.ekeko) are trying to track the cause of some indeterminism with respect to the solutions to a path query over a control flow graph. To this end, we wrote a small test case that mimics the qwal part of the query. This test case works under core.logic 0.7.5, but exhibits incorrect behavior in the latest release.

The test case illustrates two problems:
First, the solutions to two logically equivalent path queries return differ. The query that uses predicate test-2 returns the correct amount of solutions (4 nodes encountered on the single path through a graph).
The query that uses predicate test-1 returns just 2 nodes.

damp.tabling-test> (test-1)
(:baz :quux)
damp.tabling-test> (test-2)
(:foo :bar :baz :quux)

Both queries skip an arbitrary number of nodes (using patho), capture a node to obtain a solution (through unification), and skip an arbitrary number of nodes.
The predicates only differ in the last step: either this is achieved by including 'patho' as the last element in the last that is passed to solve-goals, or by calling 'patho' separately after the call to solve-goals. Logic-wise, both queries should be equivalent. Note that omitting 'tabled' from the definition of 'patho' causes the tests to behave as expected.

Second, we encountered a minor issue concerning the number of results returned by the faulty query. This sometimes changes when the file is recompiled.

damp.tabling-test> (test-1)
(:quux)
;;recompile
damp.tabling-test> (test-1)
(:baz :quux)

More comments can be found in the code for the test case that is attached.



 Comments   
Comment by David Nolen [ 13/Feb/13 3:10 PM ]

Ok, I've confirmed the issue. Will look into it.

Comment by David Nolen [ 11/Mar/13 8:37 AM ]

I believe I have found the issue as well as the source of the nondeterminism. When we switched to sets away from lists for the cache I didn't fully think through the implications. The nondeterminism arises from the use of sets. We actually want a hybrid cache datatype that works like a list but can efficiently check for the existence of a cached answer w/o scanning the list.

Comment by David Nolen [ 13/Mar/13 8:51 AM ]

fixed, http://github.com/clojure/core.logic/commit/53cbfca4b7062e09d7c7ff43fccec70e46d36ea1





[LOGIC-62] distincto bug Created: 25/Oct/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

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


 Description   
(run 16 [q] (distincto q) (everyo #(membero % (range 3)) q))
;; returns (() [0] [1] [2] (0 0) (0 1) (1 0) (0 2) (1 1) (2 0) (1 2) (2 1) (2 2) (0 0 0) (0 0 1) (0 1 0)), incorrect


 Comments   
Comment by David Nolen [ 26/Oct/12 12:39 AM ]

fixed, http://github.com/clojure/core.logic/commit/36cd3dfabd4848bce1c57fe5147b7f6c353de1b6





[LOGIC-61] partial-map in ClojureScript does not correctly unify map members Created: 25/Oct/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

Type: Defect Priority: Major
Reporter: Paul deGrandis Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

In the most recent changes to the core.logic's CLJS support (LOGIC-60), partial-map does not correctly unify the members within the map:

(m/run* [q]
  (m/fresh [pm x]
    (m/== pm (partial-map {:a x}))
    (m/== pm {:a 1 :b 2})
    (m/== x q))))
=> (1)

but,

(m/run* [q]
  (m/fresh [pm x]
    (m/== pm (partial-map {:a x}))
    (m/== pm {:a 1 :b 2})
    (m/== pm q))))
=> (#PMap{:a <lvar:x_3>})

The latter should unify to {:a 1}



 Comments   
Comment by David Nolen [ 26/Oct/12 6:04 PM ]

fixed, http://github.com/clojure/core.logic/commit/d39fd90ae096c1a940e79ea898a9f86d4b106362





[LOGIC-41] Unexpected behavior when using functions Created: 31/May/12  Updated: 28/Jul/13  Resolved: 31/May/12

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

Type: Defect Priority: Major
Reporter: Jens Bendisposto Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: None


 Description   

Not sure if this is a bug, but it seems a bit strange

=>(defn cp [a b c d] (== a b) (== c d))
=>(run* [q] (fresh [x y] (cp 1 x 2 y) (== q [x y])))
([_.0 2])

My expectation was that I get ([1 2)]



 Comments   
Comment by David Nolen [ 31/May/12 2:50 PM ]

This is not a bug. You can't just combine two unifications like that. They must be combined under fresh or all.





[LOGIC-109] custom defc constraint does not run Created: 28/Jan/13  Updated: 28/Jul/13  Resolved: 29/Jan/13

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

Type: Defect Priority: Major
Reporter: Kevin Downey Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

I have a custom constrain defined using defc, it looks like

(defc string-containsc [x y]
  (and (string? x)
       (.contains x y)))

I have a little core.logic program

(defn t []
  (logic/run* [q]
    (c/string-containsc q "foo")
    (logic/== q 1)))

the result of calling t is (1)

if I change the order of the goals:

(defn t []
  (logic/run* [q]
    (logic/== q 1)
    (c/string-containsc q "foo")))

the result of (t) is ()



 Comments   
Comment by David Nolen [ 28/Jan/13 10:50 PM ]

Possible fix in master, http://github.com/clojure/core.logic/commit/c0a5ea982624c9e9af869be0b653bf83f60de062

Does this work for you?

Comment by Kevin Downey [ 29/Jan/13 11:07 AM ]

yep, thanks

Comment by David Nolen [ 29/Jan/13 11:26 AM ]

fixed





[LOGIC-22] Unqualified Symbols at Macroexpansion via defrel Created: 24/Nov/11  Updated: 28/Jul/13  Resolved: 25/Nov/11

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

Type: Defect Priority: Major
Reporter: Ambrose Bonnaire-Sergeant Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

https://gist.github.com/1392568

The particular problem here is because the call to "to-stream" in "clojure.core.logic/extend-rel" isn't namespace qualified.

Looking through the implementation of the facts, there are some strange things going on with the macros.

Seems to be some more unqualified symbols representing vars in "extend-rel".

Also, why is clojure.core.logic/f-sym and clojure.core.logic/a-sym being used instead of gensym?



 Comments   
Comment by David Nolen [ 25/Nov/11 3:35 PM ]

Fixed, https://github.com/clojure/core.logic/commit/10d9d9d78a960256c787e37c26ee24ee57d05751





[LOGIC-5] cannot unify an lcons currently Created: 01/Jun/11  Updated: 28/Jul/13  Resolved: 02/Jun/11

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

Type: Defect Priority: Major
Reporter: Kevin Downey Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

if you have an lcons in your pattern somehow (modify replace-lvar to emit lcons for unifying lvars to the head and tail of a seq) currently you will get an exception because unify.clj uses metadata to pass the list of lvars around and lcons don't support metadata, so lcons at the toplevel get an exception when trying to attach metadata.

either lcons needs to support metadata or the list of lvars should be passed around some other way.



 Comments   
Comment by Kevin Downey [ 02/Jun/11 4:50 PM ]

dcf03a7f474da22b3a5889a37ac29c125026fceb adds metadata support to lvar





[LOGIC-102] generalize the notion of hash for robustness Created: 07/Jan/13  Updated: 28/Jul/13  Resolved: 07/Jan/13

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-102.diff     File refactoring.diff    

 Description   

The second nom/hash throws an exception, because the nom/hash constraint is ran before the predc one.

(is (= (run* [q]
         (nom/fresh [x]
           (fresh [y]
             (predc y nom? `nom?)
             (nom/hash y x)
             (== y 'foo))))
      ()))

(is (= (run* [q]
         (nom/fresh [x]
           (fresh [y]
             (nom/hash y x)
             (predc y nom? `nom?)
             (== y 'foo))))
      ()))

Perhaps, we can generalize the notion of hash.



 Comments   
Comment by David Nolen [ 07/Jan/13 10:52 AM ]

Hmm but why throw in nom/hash like that instead of just failing?

Comment by David Nolen [ 07/Jan/13 10:59 AM ]

Closed wrong ticket

Comment by Nada Amin [ 07/Jan/13 11:11 AM ]

ok, seems reasonable to fail.

The fix to logic-101 is not entirely satisfactory, because we can now get constraints like _1#[_1]. so i think i also want to not use predc (but still use fixc), but have a custom constraint instead of the predc that takes the two rands into account.

implementing this now.

Comment by Nada Amin [ 07/Jan/13 12:39 PM ]

The patch logic-102.diff gives up on predc and fixc, and instead does a lot of ugly special-casing to cover the new TDD test cases.

Not too happy about this change...

Comment by David Nolen [ 07/Jan/13 1:23 PM ]

Is there something we could do to make it easier to rely on `fixc` and `predc`? Or is there some lacking feature of constraints?

Comment by David Nolen [ 07/Jan/13 1:52 PM ]

Also if you're OK w/ this patch, more than happy to move forward w/ this for now and it can be improved later.

Comment by Nada Amin [ 07/Jan/13 2:38 PM ]

OK, as discussed, please go ahead with the patch, and I'll think of some alternatives / refactoring soon.

Comment by David Nolen [ 07/Jan/13 7:06 PM ]

fixed, http://github.com/clojure/core.logic/commit/417246ad0d854f9f82ae3b5aeb566ea00249eb2c

Comment by Nada Amin [ 08/Jan/13 7:04 AM ]

refactoring.diff refactors the logic a bit. Hopefully it's more readable.

For now, it seems too much trouble for the gain to generalize hash or try to write it using more primitive constraints.

Comment by David Nolen [ 08/Jan/13 7:12 AM ]

Makes sense will apply later today.

Comment by Nada Amin [ 11/Mar/13 12:27 PM ]

I am going to apply the refactoring to master.

Comment by Nada Amin [ 11/Mar/13 12:30 PM ]

Applied in https://github.com/clojure/core.logic/commit/43d325bd8e3770f3483cc8be7d332adfae3a6a96





[LOGIC-46] Unification on Struct Maps Causes Error Created: 02/Aug/12  Updated: 28/Jul/13  Resolved: 04/Oct/12

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

Type: Defect Priority: Major
Reporter: Daniel Gregoire Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Unless two struct maps satisfy identical?, attempting to unify on them results in an error. Consider the following:

(defstruct element :tag :attrs :content)
(def an-element (struct element :div [] "bar"))

(run* [q]
  (membero an-element (all-elements))

Results in:

java.lang.RuntimeException: Can't remove struct key
 at clojure.lang.Util.runtimeException (Util.java:156)
    clojure.lang.PersistentStructMap.without (PersistentStructMap.java:178)
    clojure.lang.RT.dissoc (RT.java:736)
    clojure.core$dissoc.invoke (core.clj:1404)
    clojure.core.logic$eval4245$fn__4246.invoke (logic.clj:1430)
    clojure.core.logic$eval2230$fn__2231$G__2221__2240.invoke (logic.clj:36)
    clojure.core.logic$eval4139$fn__4140.invoke (logic.clj:1280)
    clojure.core.logic$eval2050$fn__2051$G__2041__2060.invoke (logic.clj:18)

During unification for IPersistentMap, the two map-like arguments have the just-compared entry removed with dissoc on recursion. For struct maps, this obviously throws the above error, whereas for Clojure records it "downgrades" them to regular maps (also sub-optimal).

(Aside: I've encountered the above using Christophe Grand's Enlive library, which still uses struct maps for modeling parsed HTML/XML documents.)



 Comments   
Comment by David Nolen [ 07/Aug/12 8:48 PM ]

There is no support for unifying struct maps. Patch welcome.

Comment by David Nolen [ 27/Sep/12 9:44 PM ]

I'm considering adding a IEmptyableCollection protocol to core.logic. If you implement then we can call it when unifying maps to preserve the original type. Does this sound satisfactory?

Comment by Daniel Gregoire [ 27/Sep/12 10:16 PM ]

Per our conversation at StrangeLoop, this sounds like a nice approach, and should solve current issues both with structmaps and records.

Comment by David Nolen [ 04/Oct/12 7:20 PM ]

Fixed, http://github.com/clojure/core.logic/commit/a62e7f11f02ade156043d309dc94166c9ec581b8. The record issue will be resolved in a separate ticket.

Comment by David Nolen [ 04/Oct/12 7:30 PM ]

I refined the ticket LOGIC-58 about issues around defrecord which is really an issue around reconstructing it during reification not unification specifically.





[LOGIC-27] runtime error when using ^:index Created: 15/Feb/12  Updated: 28/Jul/13  Resolved: 13/May/12

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

Type: Defect Priority: Major
Reporter: Jason Jackson Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File index_patch    

 Comments   
Comment by David Nolen [ 20/Feb/12 2:15 PM ]

Again, please create the patch with git with the proper attribution information, thanks!

Comment by Jason Jackson [ 13/May/12 10:09 AM ]

Someone has fixed this in Master, so this issue can be closed.

Comment by David Nolen [ 13/May/12 11:36 AM ]

Fixed in master





[LOGIC-36] Unification bug in binding-map Created: 09/Apr/12  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: André Thieme Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: unify


 Description   

I tried some tests of core.unify against core.logics binding-map function and found some inconsistencies:
(binding-map '(?x ?y) '(?y ?x)) ==> {?y _.0, ?x _.0}
while core.unify returns ==> {?x ?y}



 Comments   
Comment by David Nolen [ 17/Mar/13 6:52 PM ]

fixed, http://github.com/clojure/core.logic/commit/c37212270688b1bdbbca7fb81c1fc52062b24139





[LOGIC-75] Combining maps and finite domains in core.logic returns only one result Created: 11/Dec/12  Updated: 28/Jul/13  Resolved: 12/Dec/12

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

Type: Defect Priority: Major
Reporter: Frederik De Bleser Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bug
Environment:

Clojure 1.4.0, core.logic 0.8.0-beta2



 Description   

I'm trying to combine maps with finite domains with some odd results.

A simple query using finite domains correctly returns all values:

(run* [q]
	  (fresh [x]
	    (infd x (interval 1 3))
	    (== q x)))
	
	;=> (1 2 3)

But putting this result in a map returns only the first value:

(run* [q]
	  (fresh [x]
	    (infd x (interval 1 3))
	    (== q {:foo x})))
	
	;=> ({:foo 1})

FYI this works with vectors:

(run* [q]
	  (fresh [x]
	    (infd x (interval 1 3))
	    (== q [x])))
	
	;=> ([1] [2] [3])

But lcons seems to fail as well:

(run* [q]
	  (fresh [x]
	    (infd x (interval 1 3))
	    (== q (lcons x 'foo))))
	
	;=> ((1 . foo))


 Comments   
Comment by David Nolen [ 12/Dec/12 11:53 AM ]

fixed, http://github.com/clojure/core.logic/commit/c96402f3e60b1118446b3e681d98e444e4ce417d





[LOGIC-85] another issue with predc constraint is not enforced when it could be Created: 24/Dec/12  Updated: 28/Jul/13  Resolved: 24/Dec/12

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

This returns ([1 1]) instead of ().

(run* [q]
  (fresh [x y]
    (predc y even? `even?)
    (predc x odd? `odd)
    (== x y)
    (== x 1)
    (== q [x y]))))


 Comments   
Comment by David Nolen [ 24/Dec/12 1:31 PM ]

This is actually related to the deeper problem also demonstrated by LOGIC-77. The problem is that cKanren checks constraints via "update-prefix" which calls "update" which calls "run-constraints*". "update" is called on the Substitution prior to unification. This creates all kinds of issues as it's during unification that we "migrate" constraints from one logic var to another.

I'm pondering eliminating "update" and moving "run-constraints*" lower into the system - perhaps at the level of "ext-no-check". A related change would be putting SubstValue smarts into "ext-no-check". For example a "ext-no-check" on a unbound constrained logic var would simply update its SubstValue. This is critical as SubstValue might contain constraint information that must be preserved.

Comment by David Nolen [ 24/Dec/12 6:14 PM ]

fixed, http://github.com/clojure/core.logic/commit/d4d4cd53edfd76c2f416bd699f4b4d914f880985





[LOGIC-135] membero should be updated to use disequality constraints Created: 07/May/13  Updated: 28/Jul/13  Resolved: 07/May/13

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

Type: Defect Priority: Major
Reporter: Austin Haas Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File LOGIC-135-membero-using-disequality.diff    

 Description   

William Byrd considers the version of membero that appears in core.logic to be outdated and inferior to a version that uses disequality constraints. Full discussion here: http://youtu.be/MTAhbsWUUxM?t=1h20m00s

NEW version:

(defne membero
  "A relation where l is a collection, such that l contains x"
  [x l]
  ([_ [x . tail]])
  ([_ [head . tail]]
     (!= x head)       ;; The addition of this line is the only change.
     (membero x tail)))

(run* [q] (membero q [1 1 1])) 
;; => (1)
;; The current version returns (1 1 1).

Patch to follow.



 Comments   
Comment by Austin Haas [ 07/May/13 5:33 PM ]

This patch improves membero by adding a disequality constraint. Fix for LOGIC-135.

Note that this patch removes two tests that depended on assumptions that have nothing to do with the correctness of membero.

Comment by Austin Haas [ 07/May/13 5:41 PM ]

Regarding the tests, the first broke because it assumed reified fresh lvars wouldn't include disequality constraints.

For the 2nd one, test-116-constraint-store-migrate, I have not looked into it thoroughly, but I got the impression that the test needs to be rewritten. I'd argue that it is more important to fix membero before fixing that test (but I don't know what else that test is testing).

Comment by David Nolen [ 07/May/13 10:24 PM ]

fixed http://github.com/clojure/core.logic/commit/a35c8eebfff90515796ea734ba81e3f5db041b5c





[LOGIC-3] nonrel/lvar -> nonrel/lvaro, nonrel/nonlvar -> nonrel/nonlvaro Created: 19/May/11  Updated: 28/Jul/13  Resolved: 21/May/11

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

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

Approval: Ok

 Description   

They are relations and should probably follow the naming convention for goals. This also avoids confusing newcomers when trying to to use the nonrel namespace.



 Comments   
Comment by David Nolen [ 21/May/11 1:02 PM ]

Fixed by https://github.com/clojure/core.logic/commit/d1886dcb4015143ddcb054ddc601482e914fb584





[LOGIC-67] match(e/a) in ClojureScript always creates free var Created: 14/Nov/12  Updated: 28/Jul/13  Resolved: 14/Nov/12

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

Type: Defect Priority: Major
Reporter: Thomas Karolski Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

cljsbuild 0.2.8
core.logic 0.8.0-beta2



 Description   

The following code:

(defn map-geto* [m k v]
  (matche [m]
    ([[[k v] . _]])
    ([[_ . tail]] (map-geto* tail k v))))

(run* [q] (map-geto* (seq {:title "Blub" }) :title q))

works in Clojure as expected, returning ("Blub"). However in ClojureScript I get (_.0) instead. From what I can tell, this is because within the matche clause that matches [k v], both k and v are not being matched against the upper k and v, but rather create fresh variables instead.
I can work around the issue by writing the following:

(defn map-geto* [m k v]
  (matche [m]
    ([[[k' v'] . _]] (== k k') (== v v'))
    ([[_ . tail]] (map-geto* tail k v))))

(run* [q] (map-geto* (seq {:title "Blub" }) :title q))

Is this intended behavior?



 Comments   
Comment by David Nolen [ 14/Nov/12 5:52 PM ]

fixed, http://github.com/clojure/core.logic/commit/fff0033b288a2ff80ce3bc672e1daabfa16e555b





[LOGIC-126] fd/* and fd/+ interaction bug Created: 28/Mar/13  Updated: 28/Jul/13  Resolved: 28/Mar/13

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

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


 Description   

Via this StackOverflow question http://stackoverflow.com/questions/15671823/unexpected-results-with-clojure-core-logic-using-clp-fd

(defn product-pluso [factor1 factor2 number sum]
  (fd/eq (= sum (+ number (* factor1 factor2)))))

(run* [x y]
  (fd/in x y (fd/interval 1 38))
  (product-pluso x y 2 40))

Returns too many answers. Even if we desugar into:

(run* [q]
  (fresh [x y p]
    (fd/in x y (fd/interval 1 38))
    (fd/* x y p)
    (fd/+ p 2 40)
    (== q [x y p])))

We see results which clearly violate the fd/+ constraint.



 Comments   
Comment by David Nolen [ 28/Mar/13 12:58 PM ]

It seems like we should be able to fix this at the level of update-var-dom by checking that the var doesn't already have a value in the substitution, but oddly by doing this we run into some strange non-termination behavior. I've experienced this before when trying to flip the order of checks in let-dom, but at the time I was too busy with bigger problems to look at the issue more closely.

Comment by David Nolen [ 28/Mar/13 1:01 PM ]

After digging into this some it looks like we have a fairly nice opportunity to refactor and make things considerably faster. In the Scheme version get-dom / walk are necessarily separate operations because of the implementation. This is not necessary in core.logic because of SubstValue. get-dom should always do the right thing - return the value in the substitution if present or domain otherwise. The constraint writers need not bother with walk at all.

Comment by David Nolen [ 28/Mar/13 1:27 PM ]

To be clear get-dom has different contract than walk - get-dom will return a not found value instead of a logic var. It would be nice to be able to return nil but we could image CLP(Set) and other cases where the possible values includes nil.

Comment by David Nolen [ 28/Mar/13 10:40 PM ]

fixed http://github.com/clojure/core.logic/commit/52eec3b04c2b785c84bed81671db80c2163c4967





[LOGIC-81] predc constraint is not enforced when it could be Created: 19/Dec/12  Updated: 28/Jul/13  Resolved: 20/Dec/12

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-81.diff    

 Description   

The predc number constraint fails to be enforced here.

(is (= (run* [q]
           (fresh [x]
             (== q x)
             (predc q number? `number?)
             (== x "foo")))
        ())) ;; false -- actual is ((_0 :- number?))

Inverting the first two goals gives the expected result.

(is (= (run* [q]
           (fresh [x]
             (predc q number? `number?)
             (== q x)
             (== x "foo")))
        ())) ;; OK


 Comments   
Comment by Nada Amin [ 19/Dec/12 9:12 AM ]

Actually, the problem is not specific to predc. It's an issue that addcg can overwrite a precious binding. Here is another example without predc:

(is (= (run* [q]
           (fresh [x y z]
             (== q x)
             (distinctfd [q y])
             (== y x)
             (infd q x y (interval 1 3))))
        ()) ;; false -- actual is [1 2 3]

I have a fix that I'll submit shortly.

Comment by Nada Amin [ 19/Dec/12 9:20 AM ]

Let's discuss on GitHub first: https://github.com/namin/core.logic/compare/logic-81

Comment by Nada Amin [ 20/Dec/12 9:25 AM ]

logic-81.diff include fix and tests. Since the interface for the constraint store has been modified, some tests needed to be udpated.

discussion: https://github.com/clojure/core.logic/pull/14

rebase:
https://github.com/namin/core.logic/compare/logic-81-base

Comment by David Nolen [ 20/Dec/12 9:43 AM ]

fixed, http://github.com/clojure/core.logic/commit/0f7de6ed7125df65f4450d5507341a98b151001a





[LOGIC-8] tabled goals perisist across runs Created: 08/Jun/11  Updated: 28/Jul/13  Resolved: 08/Jun/11

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

Type: Defect Priority: Major
Reporter: Pepijn de Vos Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

Tabled goals store state in the same way memoize does.

  • (run 5 [q] (tabled-goal)) and then (run 10 [q] (tabled-goal)) will both return 5 results.
  • multiple runs wil accumulate memory.


 Comments   
Comment by David Nolen [ 08/Jun/11 10:41 PM ]

Fixed by dd1a398922244b86ca8f29f9da511e21157d5b54





[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-101] nom/hash and variable noms Created: 07/Jan/13  Updated: 28/Jul/13  Resolved: 07/Jan/13

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

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-101.diff    

 Description   

It would be nice if nom/hash handled variable noms:

(run* [q]
  (nom/fresh [x]
    (fresh [y]
      (nomo y)
      (nom/hash y x)
      (== x y)))

This returns '(_0) instead of (). Fortunately, a work-around is to use != instead of nom/hash when comparing two noms. However, it's bad that this silently does something unexpected.



 Comments   
Comment by Nada Amin [ 07/Jan/13 8:05 AM ]

logic-101.diff has workaround + test.

Comment by David Nolen [ 07/Jan/13 8:34 AM ]

fixed, http://github.com/clojure/core.logic/commit/770e027858bde711121abb9267854966a4dd92ed





[LOGIC-45] add everyo (?) when we want to apply a goal to every element of a sequence. Created: 31/Jul/12  Updated: 28/Jul/13  Resolved: 15/Dec/12

Status: Closed
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: Completed Votes: 0
Labels: None


 Description   

It's a common pattern to do the following

(defn everyo [g xs]
  (if (seq xs)
    (all
      (g (first xs))
      (everyo g (next xs)))
    succeed))

We should add this to the standard library.



 Comments   
Comment by David Nolen [ 15/Dec/12 7:21 PM ]

We have everyg now - the naming and behavior should probably go through some more consideration.





[LOGIC-20] Switch conde style to use vectors instead of list Created: 17/Nov/11  Updated: 28/Jul/13  Resolved: 27/Nov/11

Status: Closed
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: Completed Votes: 0
Labels: None


 Description   

Suggested by Christophe Grand.

(defn foo [...]
  (conde
    [(g0 ...) ...]
    [(g1 ...) ...]))

We should update all the source to use this default style.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 24/Nov/11 7:51 AM ]

Anyone got a macro?

Comment by David Nolen [ 27/Nov/11 8:18 PM ]

Fixed, https://github.com/clojure/core.logic/commit/de34c3ed961b76e5cbc76169975bdc48c033beae





[LOGIC-115] fd/interval with (== lb ub) fails Created: 19/Feb/13  Updated: 28/Jul/13  Resolved: 19/Feb/13

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

Type: Defect Priority: Major
Reporter: Herwig Hochleitner Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Test case:

(run* [q] (fd/in q (fd/interval 3 3)))



 Comments   
Comment by David Nolen [ 19/Feb/13 7:38 PM ]

fixed, http://github.com/clojure/core.logic/commit/83e9cdb4247893ef0a8dbdefe61aebdca0163dbf





[LOGIC-139] to-stream fails on constraints Created: 23/Jun/13  Updated: 28/Jul/13  Resolved: 03/Jul/13

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

Type: Defect Priority: Major
Reporter: Norman Richards Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-fix-unification-on-relations.patch    

 Description   

an example:
(defrel foo n)
(fact foo 1)
(fact foo 2)

(run* [q] (fresh [x] (!= x 1) (foo x)))
=> ((_0 :- (Unable to render embedded object: File (- () not found.= (2 1))))

The problem is that to-stream uses unify, which doesn't consider constraints. Here's two alternate implementations of stream (not replacements for to-stream, but basically performing the same task). One uses unify and the other uses bind and == to unify. The bind version produces the correct results.

(defn my-stream-unify [s v vals]
(when (seq vals)
(mplus (unify s v (first vals))
(λ [] (my-stream-unify s v (rest vals))))))

(defn my-stream-bind [s v vals]
(when (seq vals)
(mplus (bind s (== v (first vals)))
(λ [] (my-stream-bind s v (rest vals))))))

(defn myval-unify [x]
(fn [s]
(my-stream-unify s x [10 20 30])))

(defn myval-bind [x]
(fn [s]
(my-stream-bind s x [10 20 30])))

(run* [q]
(fresh [x]
(!= x 80)
(myval-unify x)))

(run* [q]
(fresh [x]
(!= x 80)
(myval-bind x)))

I've fixed my use of to-stream in pldb 0.1.3 in https://github.com/threatgrid/pldb/commit/8e8036fa0fedca7bb6ccee4af41a2bf6a66ffc2b

(db-rel foo n)
(with-db (db [foo 1]
[foo 2])
(doall (run* [q]
(fresh [x]
(!= x 1)
(foo x)))))

=> (_0)

If I've analyzed and fixed the problem correctly, I'd be happy to fix this small in core.logic. (and maybe it's time to get cracking on moving pldb into core.logic?)



 Comments   
Comment by David Nolen [ 23/Jun/13 12:19 PM ]

The bind solution looks good to me. Please attach a patch, thanks!

And +1 to getting pldb into core.logic

Comment by Norman Richards [ 24/Jun/13 11:55 AM ]

https://github.com/orb/core.logic/commit/dd29620e792b55e6a114519f164de16c602a0d03.patch

Note - I could not test the change to the datomic use of to-stream, and there are no test cases covering it. If you don't have a way to verify that change (or would rather not touch that code) then we could not apply that part of the patch and leave the broken to-stream in for the datomic support.

Comment by David Nolen [ 24/Jun/13 11:59 AM ]

Can we actually get the patch attached to the ticket as a file upload? Thanks!

As far as fixing Datomic support it's not high priority, it's an experiment not a feature

Comment by Norman Richards [ 24/Jun/13 12:48 PM ]

The problem is that we either need to fix that code or leave in the broken method. I guess the best approach is to move to-stream to datomic.clj, so I did that with the attached patch.

Comment by Norman Richards [ 25/Jun/13 5:33 PM ]

Did some more testing with this. It seems that the use of mplus here eats the stack up for larger data sets. I'm working on an alternate implementation that won't blow the stack.

Comment by Norman Richards [ 25/Jun/13 7:41 PM ]

second version - doesn't blow the stack

Comment by Norman Richards [ 25/Jun/13 7:46 PM ]

Upon further reflection, to-stream really wasn't in error. It was the use of unify instead of ==. I didn't know how to apply the goal without mplus/bind. But, obviously, I can call the == goal directly to accomplish what bind was doing, and the existing choice in to-stream is sufficient to go what mplus was doing.

This second patch works on with the larger dbs I have and also passes the test case I added.

Comment by David Nolen [ 03/Jul/13 8:28 PM ]

fixed http://github.com/clojure/core.logic/commit/d00d58685764a68d4e7c6d8294ac200786c83a7e





[LOGIC-17] ClojureScript compatibility Created: 09/Oct/11  Updated: 28/Jul/13  Resolved: 24/Mar/12

Status: Closed
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: Completed Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 24/Mar/12 9:11 PM ]

fixed, https://github.com/clojure/core.logic/commit/a516fd632499c9797a745b9ff2696633904cc782





[LOGIC-71] set *reify-vars* to false for the user if the unifier is given more than 2 arguments Created: 20/Nov/12  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: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   
(unifier '(?x) '(?x) '(1))

This will fail which is surprising.



 Comments   
Comment by David Nolen [ 17/Mar/13 6:47 PM ]

fixed, http://github.com/clojure/core.logic/commit/07292792bec2694dafd4bf62b1c96580d5d270d3





[LOGIC-6] no way to unify the first of a seq to one lvar and the rest to another Created: 01/Jun/11  Updated: 28/Jul/13  Resolved: 02/Jun/11

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

Type: Enhancement Priority: Major
Reporter: Kevin Downey Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

would be nice to be able to do stuff like

(cond-m foo
(cons ?a nil) (println a))

where foo is some value, and (cons ?a nil) is pattern to match and (println a) is code to execute if it matches. (cons ?a nil) would match a sequence with one element, with ?a matching that one element.

you can sort of do this by modifying replace-lvar to turn (cons a b) into (lcons a b) this works for some cases but fails for the one given above, not sure why



 Comments   
Comment by Kevin Downey [ 01/Jun/11 4:53 PM ]

(cond-m '[(1)]
[(cons ?a nil)] a)

does actually return 1 if you making the change to replace-lvar my mistake

Comment by Kevin Downey [ 02/Jun/11 4:52 PM ]

bd9a3440977ed17648d1e57fec2ba52c95657733 adds support for unifying first and rest using (?first ?second . ?rest)





[LOGIC-143] bring pldb into core.logic Created: 06/Oct/13  Updated: 15/Oct/13  Resolved: 15/Oct/13

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

Type: Enhancement Priority: Major
Reporter: Norman Richards Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-integrate-pldb.patch     Text File 0001-remove-old-defrel.patch    
Patch: Code and Test

 Description   

This patch integrates pldb into core.logic, using the technique suggested by David Nolen of adding the pldb db to the substitution metadata. This worked really well. I've tested this integration against the threatgrid codebase, and with the exception of a couple edge cases where we were using facts-for directly for testing, it is a drop in replacements for pldb, requiring only the namespace change of pldb -> clojure.core.logic.pldb.

I moved logic-dbs into the clojure.core.logic so that they could automatically be included in the various run macros and the existing pldb/with-db bindings. I've also added run-db macros that allow explicit declarations where that is desirable. This seems reasonable to me, but I'm open to suggestions.



 Comments   
Comment by Norman Richards [ 06/Oct/13 11:32 AM ]

My working branch: https://github.com/orb/core.logic/tree/pldb

Comment by Norman Richards [ 06/Oct/13 2:27 PM ]

This doesn't remove the old rel/fact code. I'm not sure what way you want to take that. Also, I need to add docs when we're happy with the look of things.

Comment by David Nolen [ 06/Oct/13 2:37 PM ]

Would prefer to just switcheroo if possible, and then ask people to give the new stuff a spin. If everyone is OK with then we can cut a release. Has anyone else contributed code to pldb besides yourself? Just need to make sure we have CAs for everyone. Might need to get a verbal something from them on clojure-dev as well.

Comment by Norman Richards [ 06/Oct/13 2:46 PM ]

Craig Brozefsky is the only other pldb contributor. He does have a CA.

Comment by Norman Richards [ 07/Oct/13 9:26 AM ]

Patch 2 removes all the old rel code/tests. I forgot to turn off emacs whitespace cleanup, so I trivially touched a lot of lines with trailing whitespace that didn't need to be. I usually go back and fix up the commits, but if it's ok, maybe we can just put in the whitespace cleanup too so it'll be easier to work with in the future.

I'll send a patch 3 with the doc updates later.

Comment by David Nolen [ 11/Oct/13 10:51 AM ]

Can we get a new Patch 2 updated to apply to HEAD? Thanks.

Comment by Norman Richards [ 13/Oct/13 9:57 AM ]

This patch (0001-remove-old-defrel.patch) is from the current master (335226f).

Comment by David Nolen [ 15/Oct/13 10:50 PM ]

fixed, http://github.com/clojure/core.logic/commit/1cdb5393aa9b5cac53de76e66d09b2555a1cd002





[LOGIC-145] partial-map bug Created: 26/Nov/13  Updated: 26/Nov/13  Resolved: 26/Nov/13

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

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


 Description   
(run* [x y]
  (== y {:baz "woz"})
  (== (partial-map {:foo x}) {:foo y}))

Fails with an exception about LVar not being castable to PMap.



 Comments   
Comment by David Nolen [ 26/Nov/13 1:18 AM ]

fixed,https://github.com/clojure/core.logic/commit/737452044d8feeebd908b6fb0cfb12f3370b58f3





[LOGIC-147] polymorphic conjo constraint Created: 03/Dec/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

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


 Description   

Would work like cons but when arguments ground would dispatch to conj.



 Comments   
Comment by David Nolen [ 03/Dec/13 11:46 PM ]

fixed, https://github.com/clojure/core.logic/commit/c0f69ab5f43567c5a9f8932b187c51a42ed2a5da





[LOGIC-148] -jonc protocol to support conjo Created: 03/Dec/13  Updated: 04/Dec/13  Resolved: 04/Dec/13

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

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


 Description   

This would allow the operation to be reversible.



 Comments   
Comment by David Nolen [ 04/Dec/13 12:17 AM ]

fixed,
https://github.com/clojure/core.logic/commit/9f86dbab5c8edc41c22a7ecafcce3b5dfa58571f





[LOGIC-151] partitiono in c.c.logic.bench is emitting calls to 1-ary version of partition Created: 15/Dec/13  Updated: 20/Dec/13  Resolved: 20/Dec/13

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

Type: Defect Priority: Major
Reporter: Nicola Mometto Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Running clojure.tools.analyzer over core.logic raised an exception about an invocation of clojure.core/partition with a wrong arity.

It looks like it's partitiono's fault

(defne partitiono [a b c d]
  ([[x . l] _ [x . l1] _]
     (conda
       ((project [x b]
          (== (≤ x b) т))
        (partition l b l1 d))
       (partition l b c d))))

Here's the full macroexpansion:

(def partitiono (fn* ([a b c d] (fn* ([a7537] (fn* -inc ([] (clojure.core.logic.protocols/bind a7537 (fn* ([a__4345__auto__] (fn* -inc ([] (let* [x (clojure.core.logic/lvar (quote x)) l       
  (clojure.core.logic/lvar (quote l))] (clojure.core.logic.protocols/bind (clojure.core.logic.protocols/bind a__4345__auto__ (clojure.core.logic/== (clojure.core.logic/lcons x l) a)) (fn*       
  ([a__4345__auto__] (fn* -inc ([] (let* [l1 (clojure.core.logic/lvar (quote l1))] (clojure.core.logic.protocols/bind (clojure.core.logic.protocols/bind a__4345__auto__ (clojure.core.logic/==   
  (clojure.core.logic/lcons x l1) c)) (fn* ([a7544] (clojure.core.logic.protocols/ifa ((fn* ([a7546] (let* [x (clojure.core.logic/walk* a7546 x) b (clojure.core.logic/walk* a7546 b)] ((fn*      
  ([a__4345__auto__] (fn* -inc ([] (let* [] (clojure.core.logic.protocols/bind a__4345__auto__ (clojure.core.logic/== (clojure.lang.Numbers/lte x b) true))))))) a7546)))) a7544)                 
  [(clojure.core/partition l b l1 d)] (new clojure.lang.Delay (fn* ([] (clojure.core.logic.protocols/ifa (clojure.core/partition a7544) [l b c d] nil)))))))))))))))))))))))))))

Note the "(clojure.core/partition a7544)" near the end.

I am not familiar with core.logic so I don't know if this is simply a typo somewhere or a deeper bug so I set the priority to Major.



 Comments   
Comment by David Nolen [ 20/Dec/13 12:18 PM ]

fixed, https://github.com/clojure/core.logic/commit/dba36dd1219ee45812aaa3ffb558f176072e7d3a





[LOGIC-30] Add persistent memory tables Created: 09/Mar/12  Updated: 05/Jan/14  Resolved: 05/Jan/14

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

Type: Enhancement Priority: Major
Reporter: Brian Goslinga Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Added-persistent-memory-tables.patch    
Patch: Code and Test

 Description   

Rels currently complect identity and value, and are not first class. This enhancement provides a single-arity relation as a first class persistent value. Equality (and hash code) is defined in terms of the ITableRel protocol, leaving the door open for alternative implementations.

The implementation provide in the attached patch is a hair faster than Rels in the single index case. The query strategy used in the multiple index case may or may not be faster than the one employed by Rels depending on the data. This could easily be made configurable, if desired.



 Comments   
Comment by David Nolen [ 17/Mar/13 6:53 PM ]

ThreatGRID has a really nice simple implementation going here that they are already using in production - http://github.com/threatgrid/pldb. We should probably just integrate it.

Comment by Ivo Wever [ 05/Jan/14 9:37 AM ]

Has been done in https://github.com/clojure/core.logic/commit/1375f34ef42ee6b288ccb110b5c8c4aeb87a39a9, which is included in latest release.

Comment by David Nolen [ 05/Jan/14 9:39 AM ]

Thanks for the bump.





[LOGIC-160] Disequality on pairs not respected Created: 06/Jul/14  Updated: 06/Jul/14  Resolved: 06/Jul/14

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

Type: Defect Priority: Major
Reporter: Igor Wiedler Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

I've found some cases where disequality and equality on the same value both succeed:

(run* [q]
      (fresh [a d]
             (!= (lcons a d) '(2))
             (== (lcons a d) '(2))
             (== q [a d])))
;= ([2 ()])

Not sure if this is somehow intended, but it looks like a bug to me.



 Comments   
Comment by Igor Wiedler [ 06/Jul/14 11:25 AM ]

Here is another case that seems related (although it might be a separate issue):

(run* [q]
      (fresh [d]
             (!= q (lcons 5 d)))
      (== q '(5 6 7)))
;= ((5 6 7))
Comment by David Nolen [ 06/Jul/14 2:24 PM ]

fixed https://github.com/clojure/core.logic/commit/5221af81fcc6d391c7db5841807ac2daa14926d6





[LOGIC-149] pair used in fd namespace Created: 12/Dec/13  Updated: 06/Jul/14  Resolved: 06/Jul/14

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

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


 Description   

https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic/fd.clj#L40, used without being included via the namespace.



 Comments   
Comment by David Nolen [ 06/Jul/14 2:27 PM ]

just made pair public in master





[LOGIC-15] Improved docstrings for relations Created: 31/Aug/11  Updated: 28/Jul/13  Resolved: 24/Nov/11

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

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Added-clearer-docstrings-to-relations.patch     Text File 0001-Change-documentation-like-Art-of-Prolog.-Tiny-change.patch     Text File 0002-Added-clearer-docstrings-to-relations.patch    
Patch: Code

 Description   

I have improved the docstrings of some relations in the prelude, inspired by The Art of Prolog.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 31/Aug/11 2:28 AM ]

I've revised the docstrings in light of considering sequences with improper tails.

I've adopted a convention where, if the relation doesn't care whether a collection is proper/improper, I just say it's "a collection".

If it does care, I say it "is a proper collection".

Comment by Ambrose Bonnaire-Sergeant [ 31/Aug/11 11:31 PM ]

Please don't merge this until we have docstring support for defne. I'll revise the patch accordingly.

Comment by David Nolen [ 20/Nov/11 3:19 PM ]

We have docstring support now right?

Comment by Ambrose Bonnaire-Sergeant [ 20/Nov/11 3:36 PM ]

Yep I'll fix revise the patch in the next day or so.

Comment by Ambrose Bonnaire-Sergeant [ 24/Nov/11 7:41 AM ]

New patch, ignore other patches. Also a tiny change to "log" to make its arguments like println.

Comment by David Nolen [ 24/Nov/11 9:58 AM ]

Fixed, https://github.com/clojure/core.logic/commit/cc9512e8f628be274a5aa4c9f31bb0c7464a8c4e





[LOGIC-42] Generalize run to accept multiple logic vars Created: 13/Jun/12  Updated: 28/Jul/13  Resolved: 14/Jun/12

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

Type: Enhancement Priority: Minor
Reporter: Gary Fredericks Assignee: Gary Fredericks
Resolution: Completed Votes: 0
Labels: None

Attachments: File LOGIC-42.diff    

 Description   
(run 1 [x y z]
  ...goals...)

;; equivalent to

(run 1 [q]
  (fresh [x y z]
    (== q [x y z])
    ...goals...))


 Comments   
Comment by Gary Fredericks [ 13/Jun/12 7:36 PM ]

test and impl

Comment by David Nolen [ 14/Jun/12 9:19 AM ]

fixed, http://github.com/clojure/core.logic/commit/7b6d8f3c34e4feca18bb645282adee7aeef68ac7





[LOGIC-34] Unification should carry along metadata Created: 26/Mar/12  Updated: 28/Jul/13  Resolved: 28/Mar/12

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

Type: Defect Priority: Minor
Reporter: Kevin Lynagh Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 34-unification-metadata.txt    
Patch: Code and Test

 Description   

Unification should not swallow metadata:

(run* [q]
(== q (quote ^:haz-meta-daytuhs (form form form))))

should yield

(^:haz-meta-daytuhs (form form form))



 Comments   
Comment by Kevin Lynagh [ 26/Mar/12 11:04 PM ]

Also available at

https://github.com/lynaghk/core.logic/tree/34-unification-metadata

Comment by David Nolen [ 26/Mar/12 11:10 PM ]

That doesn't seem right. Metadata should be available on the form but not present in the result of the query.

Comment by Kevin Lynagh [ 26/Mar/12 11:36 PM ]

I'm not sure what you mean; if you unify the query and a form with metadata, then the result should have that same form with the same metadata.

In that example I have (set! print-meta true); in the usual repl the result is just ((form form form)).

Comment by David Nolen [ 26/Mar/12 11:41 PM ]

Oh gotcha, sorry I didn't realize you had set the compiler flag. Will take a look at the patch.

Comment by David Nolen [ 28/Mar/12 10:48 AM ]

fixed, https://github.com/clojure/core.logic/commit/7f4ad132af7a825839a12ff3c33e375610e6f315

Comment by Kevin Lynagh [ 28/Mar/12 11:11 AM ]

Rad, thanks David!





[LOGIC-50] Rel relation PersistentHashSet becomes LazySeq after issuing a retraction Created: 01/Sep/12  Updated: 28/Jul/13  Resolved: 05/Sep/12

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

Type: Defect Priority: Minor
Reporter: Aaron Brooks Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: performance

Attachments: Text File core.logic-rel-001.patch     Text File core.logic-rel-002.patch    
Patch: Code

 Description   

The first retraction of facts from a relation transforms the internal PersistentHashSet -set var+atom, which guarantees uniqueness, into a LazySeq which allows duplicate facts to be added. Once the first retraction occurs, a LazySeq persists for the rest of the life of the relation. Only the value of the primary -set var+atom is affected, not the -index var+atom values.

This issue is not an external correctness issue but does affect performance of subsequent duplicate fact additions which grow the size relation.

Preparation:

user=> (defrel foo x y)
#<user$eval4287$fn__4288 user$eval4287$fn__4288@1a9d489b>
user=> (facts foo [[:joe :man][:jane :woman][:sue :boy]])
nil
user=> foo_2-set
#<Atom@52aaf223: #{[:joe :man] [:jane :woman] [:sue :boy]}>
user=> (class @foo_2-set)
clojure.lang.PersistentHashSet
user=> (retraction foo :jane :woman)
nil

Without patch applied:

user=> foo_2-set
#<Atom@52aaf223: ([:joe :man] [:sue :boy])>
user=> (class @foo_2-set)
clojure.lang.LazySeq
user=> (facts foo [[:joe :man][:jane :woman][:sue :boy]])
nil
user=> foo_2-set
#<Atom@52aaf223: ([:sue :boy] [:jane :woman] [:joe :man] [:joe :man] [:sue :boy])>
user=> (class @foo_2-set)
clojure.lang.LazySeq

With patch applied:

user=> foo_2-set
#<Atom@31eb9b15: #{[:joe :man] [:sue :boy]}>
user=> (class @foo_2-set)
clojure.lang.PersistentHashSet
user=> (facts foo [[:joe :man][:jane :woman][:sue :boy]])
nil
user=> foo_2-set
#<Atom@31eb9b15: #{[:joe :man] [:jane :woman] [:sue :boy]}>
user=> (class @foo_2-set)
clojure.lang.PersistentHashSet

I've filed this as a Minor issue as it does not affect core.logic correctness and degraded performance can be avoided by not re-asserting duplicate facts.

I will also issue a GitHub pull request which can be used or ignored at your convenience.



 Comments   
Comment by David Nolen [ 02/Sep/12 5:45 PM ]

Thanks! Is this meant to be applied to master?

Comment by Aaron Brooks [ 03/Sep/12 6:56 PM ]

(cf. here and GitHub I'll keep this thread on JIRA.) Yes, this is targeted for master. I don't know if this warrants a release unto itself.

Comment by Aaron Brooks [ 04/Sep/12 9:17 AM ]

I forgot to mention that I needed to add "src/test/clojure" to the project.clj :source-paths vector to get lein1/2's test command to run the tests. Is that expected? Is there another way to run the tests that I'm missing? I'm happy to file a separate ticket/patch to address this if project.clj needs to be modified.

Comment by David Nolen [ 04/Sep/12 9:25 AM ]

Thanks for the information. Will apply to master. I actually run tests with "mvn test", I've updated :source-paths so other people can run the tests with lein.

Comment by David Nolen [ 04/Sep/12 9:26 AM ]

I tried to apply the patch but I'm getting a "Patch format detection failed".

Comment by Aaron Brooks [ 04/Sep/12 4:16 PM ]

The attached patch should work fine with git-apply (in either "cat foo.patch |git apply" or "git apply foo.patch" form). I made the GitHub pull request as I figured that would be the easiest path to pull the changes in.

Comment by David Nolen [ 04/Sep/12 6:04 PM ]

Yes the patch is not properly formatted and we're not supposed to take pull requests. The patch is missing attribution info. I normally apply patches with "git am foo.patch". I used the following guide for figuring out how to generate patches that can be applied with "git am", http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git.

Comment by Aaron Brooks [ 05/Sep/12 9:25 AM ]

My apologies for the extra run-around here. I've attached an -002 version of the patch created with git-format-patch which should be amenable to git-am.

Comment by David Nolen [ 05/Sep/12 11:32 AM ]

fixed, http://github.com/clojure/core.logic/commit/9bc6eb42be28bfd2b493657344f6eea8f5ed657c. pushing out a 0.8.0-alpha3 release as well.





[LOGIC-51] fd comparison relations behave strange when used with literals Created: 07/Sep/12  Updated: 28/Jul/13  Resolved: 26/Oct/12

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

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

java version "1.7.0_07"
OpenJDK Runtime Environment (IcedTea7 2.3.2) (Gentoo build 1.7.0_07-b30)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

org.clojure/clojure "1.5.0-alpha4"
org.clojure/core.logic "0.8-alpha3"



 Description   

The fd comparison relations always succeed when used with strings or a string and an integer:

user> (run* [q]
 (<=fd "foo" "bar"))
(_.0)
user> (run* [q]
 (<=fd "foo" 1))
(_.0)
user> (run* [q]
 (<=fd 1 "bar"))
(_.0)

IMHO, they should always fail if one argument is not a integer.

Furthermore, you get an exception when comparing integers and the larger integer is given first.

user> (run* [q]
 (<=fd 1 2))
(_.0)  ;; That's correct, but...
user> (run* [q]
 (<=fd 2 1))
IllegalArgumentException No implementation of method: :member? of protocol: #'clojure.core.logic/ISet found for class: nil  clojure.core/-cache-protocol-fn (core_deftype.clj:533)

I'd expect that comparisons of two integers should always work. You can circumvent this issue by unifying the numbers with some logic variables first, but is that really needed?

user> (run* [q]
 (fresh [a b]
  (== a 1)
  (== b 2)
  (<=fd a b)))
(_.0)
user> (run* [q]
 (fresh [a b]
  (== a 1)
  (== b 2)
  (<=fd b a)))
()

The first issue cannot be circumvented using this approach, though.

user> (run* [q]
 (fresh [a b]
  (== a "foo")
  (== b 2)
  (<=fd b a)))
(_.0)
user> (run* [q]
 (fresh [a b]
  (== a "foo")
  (== b 2)
  (<=fd a b)))
(_.0)
user> (run* [q]
 (fresh [a b]
  (== a "foo")
  (== b "bar")
  (<=fd a b)))
(_.0)
user> (run* [q]
 (fresh [a b]
  (== a "foo")
  (== b "bar")
  (<=fd b a)))
(_.0)


 Comments   
Comment by David Nolen [ 07/Sep/12 11:14 AM ]

Thanks for the report will look into it.

Comment by David Nolen [ 26/Oct/12 1:06 AM ]

I see no particular need to validate inputs. The other issues should be resolved in one of the latest betas.

Comment by Tassilo Horn [ 26/Oct/12 2:01 AM ]

> I see no particular need to validate inputs.

Well, the reported behavior ("every non-integer is both smaller and greater than anything") is likely to hide bugs in queries. But hey, even if you don't see a particular need, something you did fixed that problem anyhow.

This is with 0.8.0-beta1:

user> (run* [q] (<=fd 23 "1"))
IllegalArgumentException No implementation of method: :ub of protocol: #'clojure.core.logic/IInterval found for class: java.lang.String  clojure.core/-cache-protocol-fn (core_deftype.clj:562)
user> (run* [q] (<=fd "1" 23))
IllegalArgumentException No implementation of method: :lb of protocol: #'clojure.core.logic/IInterval found for class: java.lang.String  clojure.core/-cache-protocol-fn (core_deftype.clj:562)

IMO, both an exception and simply failing would be ok in those situations. Exception like now is probably even better.

> The other issues should be resolved in one of the latest betas.

Yes, it is. Thanks a lot, David! Feel free to close this issue.

Comment by David Nolen [ 26/Oct/12 7:04 AM ]

Thanks for the update!





[LOGIC-13] defne and variants should support docstring Created: 30/Aug/11  Updated: 28/Jul/13  Resolved: 20/Nov/11

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

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Added-metadata-support-for-defne-and-friends-with-so.patch     Text File 0001-PATCH-Added-metadata-support-for-defne-and-friends-w.patch    

 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 31/Aug/11 12:05 AM ]

I can do this if you want.

Comment by Ambrose Bonnaire-Sergeant [ 31/Aug/11 11:28 PM ]

Attached patch with brief tests.

I yanked a function from old clojure.contrib.def and put it in clojure.core.logic.match. IMO not worth an extra dependency, if it's compatible with Clojure 1.3 at all.

Comment by David Nolen [ 31/Aug/11 11:54 PM ]

If it works with with 1.3 this is ok by me.

Comment by Ambrose Bonnaire-Sergeant [ 01/Sep/11 9:23 PM ]

The tests pass under Clojure 1.3 beta2.

Comment by David Nolen [ 13/Nov/11 10:19 PM ]

Sorry for taking so long to look at this. This looks cool, mind tweaking it for 0.6.5? This patch doesn't apply since I moved everything into the same namespace. Thanks.

Comment by Ambrose Bonnaire-Sergeant [ 20/Nov/11 12:00 AM ]

Added new patch for 0.6.5

Comment by David Nolen [ 20/Nov/11 3:17 PM ]

Fixed, https://github.com/clojure/core.logic/commit/b47c86029468bb76d0f3d3fdfa900c8f1516a31b





[LOGIC-93] eliminate FDConstraint, use a template instead of delegation Created: 03/Jan/13  Updated: 28/Jul/13  Resolved: 17/May/13

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

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Currently the all different goals will exhibit entailment issues since they have implementations of `IRelevant` that just return `true`.



 Comments   
Comment by David Nolen [ 07/Jan/13 7:03 PM ]

FD constraints are always forced at the end so this is not a blocker.

Comment by David Nolen [ 17/May/13 12:57 AM ]

fixed





[LOGIC-100] pruning of unsatisfiable non-ground disequalities Created: 07/Jan/13  Updated: 28/Jul/13  Resolved: 07/Jan/13

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

Type: Defect Priority: Minor
Reporter: Nada Amin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-100.diff     File logic-100-rebase.diff    

 Description   

Not sure whether we actually want to do anything about this.

When running this snippet,

(run* [q]
  (fresh [a b]
    (== q [a b])
    (!= a q)))

we get the result:

(([_0 _1] :- (!= (_0 [_0 _1]))))

The reified != constraint is arguably spurious, because of the occurs-check.

Even if we instantiate the a:

(run* [q]
  (fresh [a b]
    (== q [a b])
    (!= a q)
    (== a 1)))

we get the result:

(([1 _0] :- (!= (1 [1 _0]))))

while there is no way the != constraint can be satisfied.

Thoughts?



 Comments   
Comment by Nada Amin [ 07/Jan/13 7:25 AM ]

logic-100.diff contains a hackish fix: use unify instead of not= to deal with non-ground terms. Also, don't add the constraint if you know that some pairs cannot be unified upfront (this is needed b/c disunify and unify are not consistent wrt occurs-check).

Comment by David Nolen [ 07/Jan/13 8:37 AM ]

Well it is possible to disable occurs-check. Why can't we just use the existing occurs-check fn to do this work?

Comment by Nada Amin [ 07/Jan/13 9:35 AM ]

There are two issues. The first one is that it's too conservative to just prune != constraints by checking that ground term pairs are not=, because [1 w] and [2 z] should also be pruned. Here is an extra test case illustrating this:

(deftest test-logic-100-disequality-3
  (is (= (run* [q]
           (fresh [x y w z]
             (== x [1 w])
             (== y [2 z])
             (!= x y)))
        '(_0)))
  (is (= (run* [q]
           (fresh [x y w z]
             (!= x y)
             (== x [1 w])
             (== y [2 z])))
        '(_0))))

On master, the second one fails b/c it has the extra constraint

(!= ([1 _1] [2 _2]))

which we ought to prune.

The second issue is that disunify does not take the occurs-check into account, so it can create a !=c that is not considered runnable, but if run, would be rightly pruned by the new unify clause (if the occurs-check is enabled).

Comment by David Nolen [ 07/Jan/13 10:39 AM ]

Ok, makes sense. Can we get a new patch using master. This one doesn't apply anymore. Thanks!

Comment by Nada Amin [ 07/Jan/13 10:50 AM ]

logic-100-rebase.diff is a new patch against master. I also added the extra tests discussed above.

Comment by David Nolen [ 07/Jan/13 11:00 AM ]

fixed, http://github.com/clojure/core.logic/commit/770e027858bde711121abb9267854966a4dd92ed





[LOGIC-16] Add print goal Created: 07/Sep/11  Updated: 28/Jul/13  Resolved: 14/Nov/11

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

Type: Enhancement Priority: Minor
Reporter: Ambrose Bonnaire-Sergeant Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Wrap print and println in a goal.



 Comments   
Comment by David Nolen [ 13/Nov/11 10:16 PM ]

We actually have a goal for this - log. Is something more required?

Comment by Ambrose Bonnaire-Sergeant [ 14/Nov/11 6:13 AM ]

I was not aware of log, this can be resolved.

Comment by David Nolen [ 14/Nov/11 7:17 AM ]

already exists.





[LOGIC-83] test rel2-dup-retractions may need a fix Created: 23/Dec/12  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: Minor
Reporter: Fanny Aenvie Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

all



 Description   

src/test/clojure/clojure/core/logic/tests.clj

function rel2-dup-retractions

parentheses may need a fix -> (== ...)

changing the expected expr from '() to '(:x) does
not make this test fail for me.

i like core.logic ... thanks for making it happen



 Comments   
Comment by David Nolen [ 17/Mar/13 7:08 PM ]

fixed, http://github.com/clojure/core.logic/commit/ae66b6fe7ff36b9fbb82edad7d227ecadd4e4af4





[LOGIC-4] Don't use extend-type on Substitutions LVar or LCons Created: 20/May/11  Updated: 28/Jul/13  Resolved: 21/May/11

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

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

Approval: Ok

 Description   

We shouldn't use extend-type to add methods to types we control, unnecessary perf hit.



 Comments   
Comment by David Nolen [ 21/May/11 1:30 PM ]

Fixed by https://github.com/clojure/core.logic/commit/ade3cda90b7fb07218d311ed06583e34b29626b5





[LOGIC-2] Provide more convenient syntax for defining a series of facts Created: 18/May/11  Updated: 28/Jul/13  Resolved: 24/Jul/11

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

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

Attachments: Text File 0001-rel-defrel-extend-rel.patch     Text File rel.patch    
Approval: Ok

 Comments   
Comment by Pepijn de Vos [ 19/May/11 6:46 AM ]

Not sure if this is a separate issue, but I'd like various ways to create a relation from a seq. Possibly anonymous.

(rel [['monkey 'banana] ['foo 'bar]])

Comment by Pepijn de Vos [ 27/May/11 7:36 AM ]

Patch added for anonymous relations and extending existing relations. Removed superfluous macros in the process. API is slightly different now.

Comment by David Nolen [ 28/May/11 10:35 AM ]

The patch mostly looks good. However defrel no longer takes args and it should (this breaks some tests). The args are like documentation and in the future I'd like to support syntax like this:

(defrel child ^:index p1 ^:index p2)

For specifying which elements of the tuple to index.

Comment by David Nolen [ 24/Jul/11 1:18 PM ]

not going to do the anonymous rel bit. fact/facts are now fns not macros.





[LOGIC-19] Make it possible to define facts on a relation defined in a different namespace. Created: 12/Nov/11  Updated: 28/Jul/13  Resolved: 13/Nov/11

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

Type: Enhancement Priority: Minor
Reporter: Nicolas Buduroi Assignee: Nicolas Buduroi
Resolution: Completed Votes: 0
Labels: facts, namespace, relation

Attachments: Text File facts_ns_fix.diff    
Patch: Code

 Description   

Currently there's no way of defining facts on a relation defined in a different namespace. It would be better to make this possible.



 Comments   
Comment by David Nolen [ 13/Nov/11 10:21 PM ]

Done, https://github.com/clojure/core.logic/commit/eb6dfda6ecc3604a987f479cd42696d4d8ad685a





[LOGIC-25] Allow retraction of previously stated facts in a relation Created: 11/Jan/12  Updated: 28/Jul/13  Resolved: 18/Jan/12

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

Type: Enhancement Priority: Minor
Reporter: Michael Nygard Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: new-feature

Attachments: Text File relational-retraction.patch     Text File relational-retraction.patch     Text File relational-retraction.patch    
Patch: Code and Test

 Description   

For long-running or interactive programs, it is useful to allow facts to become "no longer" true at a point in time.



 Comments   
Comment by Michael Nygard [ 13/Jan/12 12:49 PM ]

I've found a bug in this patch. It doesn't handle indexes correctly. New patch coming soon.

Comment by Michael Nygard [ 13/Jan/12 1:42 PM ]

New patch that correctly updates indexes when retracting facts.

Comment by David Nolen [ 14/Jan/12 7:49 PM ]

This looks good but could we get a properly formatted patch w/ attribution information? Thanks!

Comment by Michael Nygard [ 15/Jan/12 11:24 AM ]

Happy to. What needs to be different for the patch to work? Also, what attribution are you looking for? Author info in the function?

Comment by David Nolen [ 16/Jan/12 4:26 PM ]

Did you make the patch with git? Git should add that information.

Comment by Michael Nygard [ 16/Jan/12 8:14 PM ]

I did make the patch with git.

Comment by David Nolen [ 18/Jan/12 11:26 AM ]

Normally git patches I've applied have a header like the following:

From 8a44aec861c91a9652f3d60093d3d556a490067e Mon Sep 17 00:00:00 2001
From: Bobby Calderwood <bobby_calderwood@mac.com>
Date: Fri, 13 Jan 2012 09:24:29 -0500
Subject: [PATCH] MultiFn implements IHash

How exactly are you creating the patch with git?

Comment by Michael Nygard [ 18/Jan/12 12:42 PM ]

I had been using git diff. New patch file attached using git format-patch. I think this is what you're looking for.

Comment by David Nolen [ 18/Jan/12 5:45 PM ]

Fixed, https://github.com/clojure/core.logic/compare/2e4bd26201...89005b726f





[LOGIC-131] Docstrings for lvaro and nonlvaro need improvement. Created: 22/Apr/13  Updated: 28/Jul/13  Resolved: 07/May/13

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

Type: Defect Priority: Minor
Reporter: Austin Haas Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: documentation

Attachments: File LOGIC-131-fix.diff    
Patch: Code

 Description   

Assuming the following definitions:

1. A term is ground if it does not contain unassociated logic variables.
2. Otherwise, it is non-ground.

My suggestions:

lvaro: A non-relational goal that succeeds if the supplied logic variable is fresh.

nonlvaro: A non-relational goal that succeeds if the supplied logic variable is not fresh.

In the case nonlvaro, it's important to recognize that the implementation only tests whether the supplied lvar is not fresh, and "not fresh" != grounded; the result could be partially instantiated. For example, nonlvaro succeeds here when its argument is neither fresh nor grounded:

(run* [q]
  (fresh [x]
    (== q [x])
    (nonlvaro q)))
;; => ([_0])


 Comments   
Comment by Austin Haas [ 22/Apr/13 12:26 PM ]

I added those initial definitions when I thought "groundedness" was the operative word, so they aren't directly relevant.

Comment by David Nolen [ 22/Apr/13 12:29 PM ]

Thanks, I'll happily accept docstring patches.

Comment by Austin Haas [ 07/May/13 2:11 PM ]

This patch changes the docstrings for lvaro and nonlvaro to be more accurate. This is a fix for LOGIC-131.

Comment by David Nolen [ 07/May/13 10:29 PM ]

fixed http://github.com/clojure/core.logic/commit/cc30fcb4f5690e928fa7103e5091b9de8aba0013





[LOGIC-65] fix for corrupted rel indexes if retracting duplicate tuples Created: 30/Oct/12  Updated: 28/Jul/13  Resolved: 30/Oct/12

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

Type: Defect Priority: Minor
Reporter: Jeff Dik Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-fix-for-corrupted-rel-indexes-if-retracting-duplicat.patch    
Patch: Code and Test

 Description   

If a duplicate tuple is retracted from a rel, the rel indexes get corrupted, resulting in a NullPointerException when the following query is run:

(defrel rel2 ^:index e ^:index a ^:index v)
(facts rel2 [[:e1 :a1 :v1]
             [:e1 :a2 :v2]])
(retractions rel2 [[:e1 :a1 :v1]
                   [:e1 :a1 :v1]
                   [:e1 :a2 :v2]])

(deftest rel2-dup-retractions
  (is (= (run* [out]
               (fresh [e a v]
                      (rel2 e :a1 :v1)
                      (rel2 e a v)
                      (== [e a v] out))))
      '()))


 Comments   
Comment by David Nolen [ 30/Oct/12 6:37 PM ]

fixed, http://github.com/clojure/core.logic/commit/715aebfbfc95f4332d98539583fd664b92e4810f





[LOGIC-40] Retractions with an empty collection produces a NullPointerException Created: 18/May/12  Updated: 28/Jul/13  Resolved: 18/May/12

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

Type: Defect Priority: Minor
Reporter: Michael Nygard Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

All.


Attachments: Text File allow_empty_collection_in_retraction.patch    
Patch: Code

 Description   

Example:

(defrel load-factor src snk lf)
(retractions load-factor [])

Results in NPE. Should do nothing without complaining.



 Comments   
Comment by David Nolen [ 18/May/12 7:24 PM ]

Fixed, http://github.com/clojure/core.logic/commit/d613316bbce889906b4ad2172970258bf0f16916





[LOGIC-80] add fne, anonymous version of defne Created: 18/Dec/12  Updated: 28/Jul/13  Resolved: 09/Jun/13

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

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

Attachments: Text File logic-80-3.patch    

 Comments   
Comment by Stanislas Nanchen [ 01/May/13 10:24 AM ]

The macros 'fnm' (and fn[eau]) use the optional argument :tabled after the argument list. Is it ok?

Comment by David Nolen [ 05/May/13 7:39 PM ]

tabling passed as an option is OK with me.

Also could we get tests? Thanks much!

Comment by Stanislas Nanchen [ 06/May/13 3:48 AM ]

I've used the existing pm tests to test the fne macro. you find it in the logic-80-2.patch. Is it what you had in mind?

It is not clear how I can test for tabled anonymous functions as the :tabled metadata is of the defn[x] vars.
Possibilities would be:

  • add meta-data to the function produced by the macro 'tabled';
  • let the function produced by tabled implement some interface/protocol.

what do you think?

Comment by David Nolen [ 07/May/13 10:31 PM ]

This looks good. Two things:

  • squashed patch
  • tabled anonymous goal patch
Comment by Stanislas Nanchen [ 09/May/13 1:38 AM ]

we're almost there

i do not understand what you mean. you prefer a separate patch for tabled anonymous goal?

Comment by David Nolen [ 09/May/13 8:11 AM ]

Sorry typo, I meant a test for the tabled anonymous goal. Thanks!

Comment by Stanislas Nanchen [ 10/May/13 10:51 AM ]

thanks, i'll do it asap.

Comment by Stanislas Nanchen [ 14/May/13 9:50 AM ]

Squashed Patch with tests for the fn[e] macros, normal and tabled.

Comment by Stanislas Nanchen [ 14/May/13 9:51 AM ]

so i finally got some time to look at it again. the patch is squashed and contains a test for the tabled anonymous goals; it just tests whether the macro code actually works.

Comment by David Nolen [ 17/May/13 12:53 AM ]

Thanks will take a look!

Comment by David Nolen [ 09/Jun/13 11:33 AM ]

fixed, http://github.com/clojure/core.logic/commit/a64ed2f3447bca78bb6f53244db5d5379ecd55f1





[LOGIC-110] Allow anonymous constraints Created: 04/Feb/13  Updated: 28/Jul/13  Resolved: 04/Feb/13

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

Type: Enhancement Priority: Minor
Reporter: Kevin Lynagh Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 7ef6256a0e36888e0539b56d489a75dcf6072d70.patch     Text File anon-constraints.patch     Text File anon-constraints.patch    
Patch: Code and Test

 Description   

Add `fnc` macro that defines anonymous constraints.
Rename `defc` to `defnc` for consistency.



 Comments   
Comment by David Nolen [ 04/Feb/13 11:36 AM ]

Can we get a squashed patch please? Thanks!

Comment by Kevin Lynagh [ 04/Feb/13 11:57 AM ]

Update with squashed patch.

Comment by Kevin Lynagh [ 04/Feb/13 3:17 PM ]

Sorry about that---exported a bad squashed patch earlier. This latest one passes all tests.

Comment by David Nolen [ 04/Feb/13 4:03 PM ]

fixed, http://github.com/clojure/core.logic/commit/f015355c6cc375294c7b6a4b29565b62f0a68e27





[LOGIC-64] Support inequalities in finite domain sugar Created: 26/Oct/12  Updated: 28/Jul/13  Resolved: 27/Oct/12

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

Type: Enhancement Priority: Minor
Reporter: Brandon Bloom Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: patch, patch,

Attachments: Text File LOGIC-64-v1.patch    
Patch: Code

 Description   

The attached patch enables the follow code:

(run* [x]
  (infd x (interval 0 9))
  (eqfd (!= 6 (* 2 x))))

You can also substitute != with <, >, >=, or <=



 Comments   
Comment by David Nolen [ 27/Oct/12 11:33 AM ]

fixed, http://github.com/clojure/core.logic/commit/423639c62584c0100f295cc87c1cf2f721e986e3





[LOGIC-74] Bug in conde (ClojureScript) Created: 26/Nov/12  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: Minor
Reporter: Kevin De Valck Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: bug
Environment:

[org.clojure/clojure "1.4.0"]
[org.clojure/core.logic "0.8.0-beta2"]



 Description   

While working on a project I found a somewhat strange behaviour. I reworked the problem in some simple predicate. Let's take this predicate foobad.

(defn foobad 
  [?bar]
  (l/project [?bar]
    (l/fresh [?var]
      (l/conde 
        [(l/== true (instance? js/Array ?bar))
          (membero ?var (seq ?bar))]))))

When running (l/run* [?f] (foobad 0)) it produces this error:

#<Error: No protocol method ISeqable.-seq defined for type number: 0>

Because 0 is not an instance of Array it should not be entering that conde clause where it tries (seq 0).

With this workaround we get a normal behaviour:

(defn foo 
  [?bar]
  (l/project [?bar]
    (l/fresh [?var]
      (l/conde 
        [(l/== true (instance? js/Array ?bar)) 
         (fresh [?s]
          (l/== ?s (seq ?bar))
          (membero ?var ?s))]))))

Running (l/run* [?f] (foo 0)) gives us (), which is what we expect.
While 0 is clearly not an instance of Array that conde clause is still executed resulting in previous error.



 Comments   
Comment by David Nolen [ 28/Dec/12 12:49 AM ]

I'm assuming this is referring the ClojureScript version of core.logic?

Comment by David Nolen [ 17/Mar/13 7:00 PM ]

This is not a bug. Goals do not delay evaluation in this way.





[LOGIC-107] Less dependencies for non-dev environments? Created: 22/Jan/13  Updated: 28/Jul/13  Resolved: 22/Jan/13

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

Type: Enhancement Priority: Minor
Reporter: Jeroen van Dijk Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: feedback


 Description   

I am considering using core.logic, but after looking into its dependencies I am hesitating. Should I really pull in datomic and google closure if I just want to use core.logic in a normal Clojure project?



 Comments   
Comment by Jeroen van Dijk [ 22/Jan/13 10:28 AM ]

Sorry I think I spoke to soon. When I include core.logic in my project it doesn't pull in other dependencies, I have been misled by the project.clj of core.logic which declares Google closure and datomic as dependencies.

Apologies for the disturbance and thanks for a great library.

Comment by David Nolen [ 22/Jan/13 10:37 AM ]

Yes the project.clj is for development purposes only. It's not used to resolve dependencies.





[LOGIC-150] deftest test-root-1 in namespace clojure.core.logic.tests missing 'is'? Created: 15/Dec/13  Updated: 20/Dec/13  Resolved: 20/Dec/13

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

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-150-v1.diff    

 Description   

The two = expressions in deftest test-root-1 should probably be wrapped in (is ...):

(deftest test-root-1 []
  (let [x (lvar 'x)
        s (ext-no-check empty-s x 1)]
    (= (root-var s x) x)
    (= (root-val s x) 1)))

Found while testing next version of Eastwood linter on a bunch of projects. It warned that the first (= ...) expression's return value was unused.



 Comments   
Comment by Andy Fingerhut [ 16/Dec/13 3:52 AM ]

Patch logic-150-v1.diff fixes the issue in the ticket description, and a few other minor ones also found by the Eastwood Clojure lint tool.

Comment by David Nolen [ 20/Dec/13 12:19 PM ]

fixed, https://github.com/clojure/core.logic/commit/5bf5147afdb0fe04da658c3573ca63a922975d05





[LOGIC-152] Correct several unit tests Created: 23/Dec/13  Updated: 30/Dec/13  Resolved: 30/Dec/13

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

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File logic-152-v1.diff    

 Description   

Found several unit tests of the form (is (= expr1) expr2) using a pre-release version of the Eastwood lint tool. They should be changed to (is (= expr1 expr2)).



 Comments   
Comment by Andy Fingerhut [ 23/Dec/13 1:07 AM ]

Patch logic-152-v1.diff corrects the issues mentioned, plus removes many unnecessary [] after test names in deftest forms.

Comment by David Nolen [ 30/Dec/13 7:22 PM ]

fixed, https://github.com/clojure/core.logic/commit/aa08c5f7775a3e2f3cc9c8eaa701d1f24753611a





[LOGIC-159] Weird behavior with negative-number domains Created: 18/Jun/14  Updated: 06/Jul/14  Resolved: 06/Jul/14

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

Type: Defect Priority: Minor
Reporter: Alex Engelberg Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure 1.6.0



 Description   

These behave as normal:
=> (run* [q]
(fd/in q (fd/interval 1 10))
(fd/* q q 9))
(3)
=> (run* [q]
(fd/* q q 9)
(== q -3))
(-3)
=> (run* [q]
(fd/in q (fd/interval -10 -1)))
(-10 -9 -8 -7 -6 -5 -4 -3 -2 -1)

This is weird:
=> (run* [q]
(fd/in q (fd/interval -10 -1))
(fd/* q q 9))
()
I think it should return: (-3)

Also weird:
=> (run* [q]
(fd/in q (fd/interval -10 10))
(fd/* q q 9))
()
I think it should return: (-3 3)



 Comments   
Comment by David Nolen [ 19/Jun/14 10:17 AM ]

As with cKanren there isn't currently any support for negative domains.





[LOGIC-12] Improved warnings/errors for pattern matching Created: 30/Aug/11  Updated: 28/Jul/13  Resolved: 01/Sep/11

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

Type: Enhancement Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File syntax-check.patch     Text File syntax-check-with-warn.patch    
Patch: Code
Approval: Ok

 Description   

I've added some simple syntax checks for the pattern matching macros like matche.

clojure.core.logic.prelude=> (let [x 1]
(matche [x]
(1 [1 1] 1)))
#<CompilerException java.lang.RuntimeException: java.lang.Exception: Expecting vector of matches, instead 1, compiling:(REPL:53)>

clojure.core.logic.prelude=> (let [x 1]
(matche [x]
([1 1] 1)))
#<prelude$eval4469$fn_4471 clojure.core.logic.prelude$eval4469$fn_4471@e9ebe1>
WARNING: Differing number of matches. Matching [1 1] against [x]

clojure.core.logic.prelude=> (let [x 1]
(matche
([1 1] 1)))
#<CompilerException java.lang.Exception: Expecting vector of arguments, instead , compiling:(REPL:58)>

Attached patch.



 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 30/Aug/11 9:01 AM ]

Whoops, the patch is missing the definition for "warn".

Comment by Ambrose Bonnaire-Sergeant [ 30/Aug/11 9:09 AM ]

Added correct patch.





[LOGIC-10] Add documentation strings to stable functions Created: 14/Jul/11  Updated: 28/Jul/13  Resolved: 20/Nov/11

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

Type: Task Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Added-docstrings.patch     Text File 0001-Added-docstrings.patch    

 Description   

Candidates:

clojure.core.logic.minikanren

  • ==
  • conde
  • exist
  • run
  • run*
  • lvar, lvar?
  • lcons, lcons?
  • llist

clojure.core.logic.prelude:

  • nilo, emptyo, conso, firsto, resto, membero

clojure.core.logic.nonrel:

  • project
  • lvaro, nonlvaro


 Comments   
Comment by Ambrose Bonnaire-Sergeant [ 18/Jul/11 11:47 AM ]

Docstrings for relational functions.

Comment by David Nolen [ 20/Jul/11 6:59 AM ]

I'd rather not document lvar/lvar?. They are not really meant to be used directly. The docstring of lcons should be changed to say that it constructs a sequence a with an improper tail if d is a logic variable. llist should read similarly.

unify should probably say "a goal which attempts to unify u and v". Goals do not return "successful" or "failed" goals. They themselves either succeed or fail.

For exist we should probably rename x-rest to lvars and g-rest to goals. In run rename rest to goals, ditto for run*.

Comment by Ambrose Bonnaire-Sergeant [ 20/Jul/11 7:07 AM ]

I thought unify was a relation, not a goal?

Comment by David Nolen [ 20/Jul/11 7:10 AM ]

There is no difference between "relation" and "goal". conso is the relational counterpart to cons - it is most definitely a goal. It will either fail or succeed based on other elements in a particular miniKanren program.

Comment by Ambrose Bonnaire-Sergeant [ 20/Jul/11 9:08 AM ]

Second iteration

Comment by Ambrose Bonnaire-Sergeant [ 20/Jul/11 9:09 AM ]

Should we document succeed and fail?

I'm not pleased with my wording on llist.

Comment by David Nolen [ 20/Nov/11 3:20 PM ]

I'm assuming this ticket is no longer relevant?

Comment by Ambrose Bonnaire-Sergeant [ 20/Nov/11 3:37 PM ]

Yes, can be closed

Comment by David Nolen [ 20/Nov/11 3:38 PM ]

fixed





[LOGIC-33] Added usage section to readme.md Created: 15/Mar/12  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: Enhancement Priority: Trivial
Reporter: Linus Ericsson Assignee: David Nolen
Resolution: Declined Votes: 0
Labels: documentation

Attachments: Text File usage-added.patch    
Patch: Code

 Description   

added a short usage section in readme.md

the latest working repo was 0.6.7 for me, so that's what in the patch. (i have signed CA)



 Comments   
Comment by David Nolen [ 17/Mar/13 7:11 PM ]

Basic usage has since been added to README.md





[LOGIC-14] Typo in docstring Created: 31/Aug/11  Updated: 28/Jul/13  Resolved: 01/Sep/11

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

Type: Enhancement Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

The docstring in clojure.core.logic.arithmatic/<= has a typo in "whether".



 Comments   
Comment by David Nolen [ 01/Sep/11 7:33 PM ]

Fixed





[LOGIC-66] Add test-paths to project.clj to be able to run tests with lein2 Created: 30/Oct/12  Updated: 28/Jul/13  Resolved: 30/Oct/12

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

Type: Enhancement Priority: Trivial
Reporter: Jeff Dik Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0002-project.clj-update-src-test-paths-to-run-tests-with-.patch    
Patch: Code

 Description   

Add test-paths to project.clj to be able to run tests with lein2. Also remove "src/test/clojure" from :source-paths.



 Comments   
Comment by David Nolen [ 30/Oct/12 6:39 PM ]

fixed, http://github.com/clojure/core.logic/commit/d36af9f47bf194f253ba84d68973d6b7e9a53774





Generated at Wed Sep 17 22:42:56 CDT 2014 using JIRA 4.4#649-r158309.