Clojure Q&A - Recent questions in core.logic

bug in core.logic with featurec searching for logic variables

Sun, 04 Dec 2022 04:39:02 +0000

Example:

user> (def tmp {\a 1})
{\a 1}
user> (logic/run* [q] (logic/featurec tmp {\a q}))
(1)
user> (logic/run* [q] (logic/fresh [x] (logic/== x \a) (logic/featurec tmp {x q})))
()

The first logic search is as-expected. The second should return the same results as the first, but it instead fails.

There are tests in core.logic that cover the other mode of featurec under fresh, ie: (logic/featurec {x q} tmp). But this mode, on the other hand, appears to not universally work.

It was recommended I post this here as I am unable to create an account with access to the Jira to file this bug.

core.logic problem

Sat, 25 Sep 2021 11:18:29 +0000

Hi,
I have encountered a problem in simple core.logic program:

(require '[clojure.core.logic :as l]

     '[clojure.core.logic.pldb :as db])

(def facts
(db/db

[In-zone 'A 'B]))

(println
(db/with-db facts

    (l/run* [q]
      (l/fresh [x y]
        (In-zone x y)
        (== q 'IN-ZONE)))))

It gives this result:

user=> (load-file "../PROGS/CL/inzone.clj")
CompilerException java.lang.ClassCastException: class clojure.core.logic.LVar cannot be cast to class java.lang.Number (clojure.core.logic.LVar is in unnamed module of loader clojure.lang.DynamicClassLoader @4d2015a9; java.lang.Number is in module java.base of loader 'bootstrap'), compiling:(/home/ru/clojure/core.logic-master/../PROGS/CL/inzone.clj:8:1)

What's wrong? No mention about numbers!

Thanks in advance for any help.

clojure.core.logic/project returning LVar instead of bound value

Wed, 05 May 2021 07:18:08 +0000

I have a packing problem somewhat adjacent to the "make change" problem described and solved in this blog post by Taylor Wood. Here is the code, transcribed with 1 addition:

(ns blah
  (:require [clojure.core.logic :refer :all :as l]
            [clojure.core.logic.fd :as fd]))

(defn productsumo [vars dens sum]
  (fresh [vhead vtail dhead dtail product run-sum]
    (conde
     [(emptyo vars) (== sum 0)]
     [(conso vhead vtail vars)
      (conso dhead dtail dens)
      (project [vhead]
        (do (println vhead) succeed))  ;;<--- Just a lame goal that should print out the head..
      (fd/* vhead dhead product)
      (fd/+ product run-sum sum)
      (productsumo vtail dtail run-sum)])))

(defn change [amount denoms]
  (let [dens (sort > denoms)
        vars (repeatedly (count dens) lvar)]
    (run* [q]
      ;; we want a map from denominations to their quantities
      (== q (zipmap dens vars))
      ;; prune problem space...
      ;; every var/quantity must be 0 <= n <= amount
      (everyg #(fd/in % (fd/interval 0 amount)) vars)
      ;; the real work
      (productsumo vars dens amount))))

user> (change 14 #{1 5 10})
<lvar:81678>
<lvar:81679>
<lvar:81680>
({10 0, 5 0, 1 14} {10 1, 5 0, 1 4} {10 0, 5 1, 1 9} {10 0, 5 2, 1 4})

When run, instead of getting the projected or current value of the LVar vhead, as I expect and have normally seen when I use project, I get the Lvar. Are there any ideas why this is the case?

My specific use case is a modification of productsumo, where I have a map of key->weight that I need to use in liue of the coll dens that is here. My initial approach - which seems reasonable - is to use project as above to unify a cost LVar based off the current value of vhead, and then use that in the product computation. Currently I keep getting back LVars instead of values.

Any ideas?

Memoization in core.logic

Sun, 29 Nov 2020 08:07:28 +0000

I'm solving a sub-part of my problem using core.logic. I'm anticipating that the declarative nature of describing the problem would lead to poor performance on large inputs.

But the setup I have is that the inputs to core.logic rarely change, but I query them a lot. So naturally I think that memoization would speed up the performance.

I could only memoize the results from top-level (l/run* form, but again that's less efficient than memoizing at every l/defne or at every call to conde, because the latter can give the same speedups as dynamic-programming does.

But I do not understand what kind of values (like LVars introduced by fresh) pass between the logical clauses. They are different from regular clojure values, and I have never even called one of the clauses (like l/== or l/membero) "normally". They are always called indirectly by l/run*.

So, do I need to do anything special if I want to memoize such defnes?

Can core.logic reason about sets?

Fri, 27 Nov 2020 19:57:39 +0000

l/membero lets you relate list-items and lists, but I did not find an equivalent method in core.logic for contains?.

I'm currently converting my set to a list to use with l/membero, but I was just wondering -- is it possible to reason about sets in general with core.logic? e.g. relating two sets and their union, and other common operations?

If a map is a coll, why can't conso take its first element?

Sun, 24 Nov 2019 20:29:56 +0000

Looking into conso's documentation, it seems that maps are not being properly considered as collections:

user> (coll? {:a 1}) ; Just for context
true
user> (first {:a 1})
[:a 1]
user> (run* [p q] (conso p q {:a 1})) ; This is the surprising part
()
user> (run* [p q] (conso p q [[:a 1]])) ; For comparison
([[:a 1] ()])
user> (doc conso) ; Docs talk about collection as expected input
-------------------------
clojure.core.logic/conso
([a d l])
  A relation where l is a collection, such that a is the first of l
  and d is the rest of l. If ground d must be bound to a proper tail.
nil

EDIT: Also doesn't work for sets:

user> (run* [p q] (conso p q #{1 3}))
()
user> (first #{1 3})
1
user> (coll? #{1 3})
true

lein deps and lein classpath fail for current core.logic, where to report?

Tue, 05 Nov 2019 22:00:30 +0000

With the most recent commit to core.logic (https://github.com/clojure/core.logic/commit/bd325069d9ded1612515d15ad578d588094a47f7), lein deps and lein classpath do not successfully complete here.

Commenting out a portion of project.clj having to do with cider-nrepl leads both to at least finish.

When I asked on slack's #core.logic about this:

commenting out the [cider/cider-nrepl "0.8.1"] portion of project.clj alows those commands to complete...

dpsutton responded with:

that's over four years old and from a time when cider wouldn't auto-inject its own dependencies. it should be removed

I don't know if it's an appropriate change, but it seems like something should change.

It wasn't clear to me where to report this, but was advised by dpsutton and seancorfield to try here.

Truncated example output (this form refused the full content) for lein deps below.

$ lein deps
clojure.lang.Compiler$CompilerException: Syntax error compiling at (cider/nrepl.clj:1:1).
#:clojure.error{:phase :compile-syntax-check, :line 1, :column 1, :source "cider/nrepl.clj"}
 at clojure.lang.Compiler.load (Compiler.java:7647)
    clojure.lang.RT.loadResourceScript (RT.java:381)
    clojure.lang.RT.loadResourceScript (RT.java:372)
    clojure.lang.RT.load (RT.java:463)
    clojure.lang.RT.load (RT.java:428)
    clojure.core$load$fn__6824.invoke (core.clj:6126)
    clojure.core$load.invokeStatic (core.clj:6125)
    clojure.core$load.doInvoke (core.clj:6109)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$load_one.invokeStatic (core.clj:5908)
    clojure.core$load_one.invoke (core.clj:5903)
    clojure.core$load_lib$fn__6765.invoke (core.clj:5948)
    clojure.core$load_lib.invokeStatic (core.clj:5947)
    clojure.core$load_lib.doInvoke (core.clj:5928)
    clojure.lang.RestFn.applyTo (RestFn.java:142)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$load_libs.invokeStatic (core.clj:5985)
    clojure.core$load_libs.doInvoke (core.clj:5969)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.core$require.invokeStatic (core.clj:6007)
    clojure.core$require.doInvoke (core.clj:6007)
    clojure.lang.RestFn.invoke (RestFn.java:421)

The order of constraits matters?

Wed, 28 Nov 2018 10:59:41 +0000

The Wiki page (https://github.com/clojure/core.logic/wiki/A-Core.logic-Primer#corelogic-is-declarative) says "...the order of constraints does not matter as far as the value of the (run* ...) expression is concerned." But I tried this example of Sudoku solver (https://gist.github.com/orb/5884956) and found that if you exchange these two lines:

(everyg #(fd/in % sdnum) board) (init-board board puzzle)

{{core.logic}} will freeze and never return the answer.

EQ conditions which match against a negative result fail to find any results.

Sun, 04 Nov 2018 19:24:19 +0000

I was trying to follow the example provided by (link: this blog post)(https://mattsenior.com/2014/02/using-clojures-core-logic-to-solve-simple-number-puzzles) and found that it only worked if I removed the conditions that test for subtraction with a negative result. I removed a lot of different things and found that even this basic example does not find any matches:

`
(ns example.core
(:refer-clojure :exclude (link: ==))
(:require (link: clojure.core.logic :refer :all))
(:require (link: clojure.core.logic.fd :as fd)))

(run* (link: q)
(fresh (link: a0 a1)

(== q (link: a0 a1))
(fd/in a0 a1 (fd/interval 1 9))
(fd/- a0 a1 -1)
;(fd/eq
;  (= (- a0 a1) -1))
))

Dependencies (though I tried clojure 1.8 and 1.9 too):
`
:dependencies (link: [org.clojure/clojure "1.7.0")

             (link: org.clojure/core.logic "0.8.11")]

locals is unbound in some calls to `p->term`

Thu, 27 Sep 2018 17:56:55 +0000

Some pattern-matching expressions that should work fail, because the dynamic variable **locals** is not bound. For example:

(matche
(link: x)
((link: '(~a))))

gives an error during macroexpansion, that contains? cannot be applied to an unbound variable:

CompilerException java.lang.IllegalArgumentException: contains? not supported on type: clojure.lang.Var$Unbound

(The referenced call to contains? is in lvar-sym?, where we check whether a variable that appears within a pattern is already a local variable.)

I believe this is what is happening:

At two places in p->term, we call map to apply p->term recursively to subpatterns: (map #(p->term % vars quoted) p), for example.
map returns a LazySeq.
By the time the elements of the LazySeq are actually forced (this happens during macro expansion), the dynamic locals variable is no longer bound.

One solution might be to wrap a (doall ...) around the two calls to map mentioned above (lines 1523 and 1529 of logic.clj).

spurious disequality constraints

Wed, 24 Jan 2018 05:56:07 +0000

As reported by Will Byrd:

`
(is (=

 (run* [q]
   (fresh [x y]
     (!= (list x y) q)))
 ;; Simplified answer should just be:
 ;;
 ;; (_0)
 ;;
 ;; There is no way to violate this constraint, since neither
 ;; _1 nor _2 is reified. Both would need to be reified to be
 ;; able to violate the constraint.
 '((_0 :- (!= (_0 (_1 _2)))))))

I have a suggested fix here: https://github.com/clojure/core.logic/compare/master...namin:fix-for-meta?expand=1
but might be worth ensuring that other test cases from mk also work as intended.

Will Byrd suggests converting this file of tests:
https://github.com/webyrd/faster-miniKanren/blob/master/disequality-tests.scm

finite domain uncomplete results

Wed, 01 Nov 2017 10:15:40 +0000

I was trying to implement a relation similar to (map + list1 list2) -> list3
My code is:

(require '[clojure.core.logic :as l])
(require '[clojure.core.logic.fd :as fd])

(defn zip+o [x y z]
  (l/conde
    [(l/== () x) (l/== () y) (l/== () z)]
    [(l/fresh [fx rx fy ry fz rz]
              (l/conso fx rx x)
              (l/conso fy ry y)
              (l/conso fz rz z)
              (fd/in fx fy fz (fd/interval 10))
              (fd/+ fx fy fz)
              (zip+o rx ry rz))]))

(def expected-solutions
  #{{:x [0 0] :y [1 1]}
    {:x [0 1] :y [1 0]}
    {:x [1 1] :y [0 0]}
    {:x [1 0] :y [0 1]}})

(l/run* [q]
        (l/fresh [x y]
                 (l/== q {:x x :y y})
                 (zip+o x y [1 1])))

;=> ({:x (1 0), :y (0 1)}
;    {:x (0 0), :y (1 1)})

I've manage to get the expected behavior (I think...) by removing the call to onceo in clojure.core.logic/enforce-constraints

(defn enforce-constraints [x]
  (all
   (force-ans x)
   (fn [a]
     (let [constrained (enforceable-constrained a)]
       (verify-all-bound a constrained)
       ((force-ans constrained) a) ;; <--- Here
       #_((onceo (force-ans constrained)) a)))))

Sadly it breaks one test...

FAIL in (test-simplefd-in-last) (tests.clj:1797)
expected: (= (run* [q] (fresh [x y z p0 p1] (== q [x y]) (fd/+ x y 9) (fd/* x 2 p0) (fd/* y 4 p1) (fd/+ p0 p1 24) (fd/in x y z (fd/interval 0 9)))) (quote ([6 3])))
  actual: (not (= ([6 3] [6 3] [6 3] [6 3] [6 3] [6 3] [6 3] [6 3] [6 3] [6 3]) ([6 3])))

I hope it will at least help you to find the real problem.

The extension of IDisunifyTerms to LCons calls seq on lcons values. LCons doesn't implement ISeq

Thu, 20 Apr 2017 01:54:40 +0000

I don't have a good repro case for this, I hit the issue in the middle of some other code.

on like 2332 or so of master you have some code like:

`
(cond
...

 (lcons? v)
  (loop [u u v (seq v) cs cs]

...
)
`

This is obviously incorrect, because anything that returns true to lcons? will throw an exception with you call seq on it.

An lvar unified with a keyword behaves differently from a keyword

Mon, 16 Jan 2017 01:39:12 +0000

(run 1 [q]
     (fresh [x]
            (== x :a)
            (== q ({:a 0} x))))
=> (nil)
(run 1 [q]
     (fresh [x]
            (== x :a)
            (== q ({:a 0} :a))))
=> (0)
(run 1 [q]
     (fresh [x]
            (== x :a)
            (== {:a 0} {x q})))
=> ()
(run 1 [q]
     (fresh [x]
            (== x :a)
            (== {:a 0} {:a q})))
=> (0)

Running rembero returns :- (!= _0 _0)

Tue, 06 Dec 2016 23:02:01 +0000

(run* (link: out)

  (fresh (link: y z)
         (rembero y (list 'a 'b y 'd z 'e) out)))

=>
((b a d _0 e)
(a b d _0 e)
((a b d _0 e) :- (!= (_1 b)) (!= (_1 a)))
((a b _0 d e) :- (!= (_0 _0)) (!= (_0 b)) ((image: = (_0 d)) ()= (_0 a))))

spec detects error in -inc macro

Tue, 13 Sep 2016 18:51:48 +0000

As reported on the Clojure mailing list by Burt:

with "1.9.0-alpha10" and core.logic "0.8.10":

(ns lwb.nd.rules
  (:refer-clojure :exclude [==])
  (:require [clojure.core.logic :refer :all]))
=> nil

with "1.9.0-alpha12" and core.logic "0.8.10":

(ns lwb.nd.rules
  (:refer-clojure :exclude [==])
  (:require [clojure.core.logic :refer :all]))
CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/fn did not conform to spec:
In: [0] val: clojure.core.logic/-inc fails spec: :clojure.core.specs/arg-list at: [:args :bs :arity-1 :args] predicate: vector?
In: [0] val: clojure.core.logic/-inc fails spec: :clojure.core.specs/args+body at: [:args :bs :arity-n] predicate: (cat :args :clojure.core.specs/arg-list :prepost (? map?) :body (* any?))
:clojure.spec/args (clojure.core.logic/-inc [] (bind (this) g))
#:clojure.spec{:problems ({:path [:args :bs :arity-1 :args], :pred vector?, :val clojure.core.logic/-inc, :via [:clojure.core.specs/args+body :clojure.core.specs/arg-list :clojure.core.specs/arg-list], :in [0]} {:path [:args :bs :arity-n], :pred (cat :args :clojure.core.specs/arg-list :prepost (? map?) :body (* any?)), :val clojure.core.logic/-inc, :via [:clojure.core.specs/args+body :clojure.core.specs/args+body], :in [0]}), :args (clojure.core.logic/-inc [] (bind (this) g))}, compiling:(clojure/core/logic.clj:1130:5)

Document how defn/implicit do with multiple goals does not work

Fri, 05 Aug 2016 12:01:05 +0000

Hi! I have a small documentation improvement proposal:

When using regular `defn` to create a relation, I've found that an empty {{(fresh [] ...)}} is needed if you want to use multiple relations and goals inside your defn:ed relation, otherwise your goals are in the implicit do from defn, and only the last one has any effect.

Simple example:

{{
defn-logic> (defn test [a b]
              (== a 1)
              (== b 2))
#'defn-logic/test
defn-logic> (run* [q] (fresh [a b]
                        (== q [a b])
                        (test a b)))
([_0 2])
defn-logic> (defn test [a b]
              (fresh []
                (== a 1)
                (== b 2)))
#'defn-logic/test
defn-logic> (run* [q] (fresh [a b]
                        (== q [a b])
                        (test a b)))
([1 2])
defn-logic>
}}

Again, this is perfectly correct and reasonable, but maybe a bit confusing for beginners, in that the implicit do "fails silently". What I'm looking for here is probably just a heads up in the Wiki docs. I couldn't find it, but maybe it exists already? I'd be happy to add it to the documentation and send a PR.

Example of unifier on wiki uses wrong syntax?

Mon, 11 Jan 2016 23:43:28 +0000

The example of clojure.core.logic.unifier/unifier on the Features wiki page is

(unifier '(?x ?y ?z) '(1 2 ?y)) ; (1 2 _.0)

Shouldn't it be something like

(unifier ['(?x ?y ?z) '(1 2 ?y)]) ; {?y 2, ?x 1, ?z 2}

?

binding to a deep nested vector takes too much time

Thu, 24 Dec 2015 11:34:11 +0000

It's probably related to how core.logic is printing out the vector structure

Following is minimal case to reproduce the issue

(ns testclj.logic
(:require (link: clojure.core.logic :as l)))

(def data (link: [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[:a)]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]])

(time (l/run* (link: q) (l/== q data)))

Extending IUnifyTerms doesn't work anymore

Wed, 16 Dec 2015 18:39:40 +0000

The procedure as described on https://github.com/clojure/core.logic/wiki/Extending-core.logic-(Datomic-example) doesn't work anymore. Clojure complains that IUnifyTerms "isn't a protocol" (even though it clearly is).

Disequality might not eliminate when `(!= (_0 _0))`

Sun, 06 Dec 2015 02:24:09 +0000

When a unification constraint and a disequality constraint are applied to the same lvars they might eliminate possibilities.

`
(run 1 [q]
(fresh [v n]
(== q v)
(!= q v)))

;=> ()
`

However when a separate disequality is interleaved the possibility is not eliminated.

`
(run 1 [q]
(fresh [v n]

(== q v)
(!= q n)
(!= q v)))

;=> ((_0 :- (!= (_0 _0)) (!= (_0 _1))))
`

I expected this to also return '().

LCons fails for inequality

Tue, 11 Aug 2015 21:03:02 +0000

The following expression results in an Exception "IllegalArgumentException Don't know how to create ISeq from: clojure.core.logic.LCons clojure.lang.RT.seqFrom (RT.java:505)", but should return ().

`
(run 1 (link: q)
(!= (lcons 1 1) (lcons 1 1)))

StackOverflowError when logic variable is unified with a set

Mon, 03 Aug 2015 09:58:47 +0000

It is pretty common to unify a variable with a vector or list of a fixed length like {{(== q (list a b))}} and then define more goals on {{a}} and {{b}} with the intention of being able to define the * query's result format. However, if one does the same using a set one gets a StackOverflowError.

Example:

`
(run* [q]
(fresh [a b]

(== q #{a b})  ;; StackOverflowError
;;(== q [a b]) ;; works
;;(== q (list a b)) ;; works, too
(conde [(== a 1)] [(== a 2)] [(== a 3)])
(conde [(== b 1)] [(== b 2)] [(== b 3)])))

Basically, what I wanted to express here is that the order of {{a}} and {{b}} is not significant so that * } gives me the unique results.

The backtrace is:

                 logic.clj:  231  clojure.core.logic/walk*/fn
                 logic.clj:  984  clojure.core.logic/eval8917/fn
             protocols.clj:   55  clojure.core.logic.protocols/eval7398/fn/G
                 logic.clj:  229  clojure.core.logic/walk*
                 logic.clj:  233  clojure.core.logic/walk*/fn
                 logic.clj:  984  clojure.core.logic/eval8917/fn
             protocols.clj:   55  clojure.core.logic.protocols/eval7398/fn/G
                 logic.clj:  229  clojure.core.logic/walk*
                 logic.clj:  233  clojure.core.logic/walk*/fn
                 logic.clj:  984  clojure.core.logic/eval8917/fn
             protocols.clj:   55  clojure.core.logic.protocols/eval7398/fn/G

[...]
`

nafc doesn't work with more complex goals

Fri, 31 Jul 2015 08:27:26 +0000

The negation as failure constraint {{nafc}} is supposed to succeed if and only if the goal provided by a relation and its args fails. The test cases just cover very simple cases like {{(nafc == q 'b)}} which is essentially equivalent to (!= q 'b) (at least to my understanding). But with a slightly more complex case, it doesn't seem to work anymore.

Example:

`
(run* [q]
(fresh [a b]

(== q (list a b))
(fd/in a b (fd/interval 1 3)) ;; fd is an alias for clojure.core.logic.fd
(fd/< a b)
(nafc membero 2 q)))

;=> ((1 2) (2 3) (1 3))
`

The constraint specifies that the number 2 must NOT be contained in the list {{q}} but still it is. I expected to get the single answer {{(1 3)}} here.

The docstring of condu is incorrect or at least confusing

Tue, 28 Jul 2015 12:00:01 +0000

The docstring of {{condu}} reads

{quote}
Committed choice. Once the head (first goal) of a clause has succeeded, remaining goals of the clause will only be run once. Non-relational.
{quote}

The sentence with respect to the once-semantics isn't correct. The head (first goal) can succeed at most once whereas the remaining goals of the clause committed to can succeed an unbounded number of times. The following example demonstrates that.

`
(defn y-or-n [x]
(conde
[(== x :y)]
[(== x :n)]))

(run* [x y]
(condu
[(y-or-n x) (== y 1)] ;; (y-or-n x) succeeds once because it's the head goal
[(== x :y) (== y 2)]))
;;=> ([:y 1])

(run* [x y]
(condu
[(== y 1) (y-or-n x)] ;; (y-or-n x) succeeds twice because it's not the head goal
[(== x :y) (== y 2)]))
;;=> ([:y 1] [:n 1])
`

The current behavior shown in the example is in compliance with miniKanren on Scheme, so it's just the docstring which isn't right. The implementation is correct.

Replacing Marker Interfaces

Fri, 24 Jul 2015 04:07:32 +0000

*Summary:* There is a pattern of {{(definterface IFoo)}} and subsequent uses of {{IFoo}} as a type marker for efficient {{(instance? IFoo x)}} checks. This pattern is not platform agnostic and could potentially block improving support for core.logic on CLJS (which does not support {{definterface}} according to [http://dev.clojure.org/jira/browse/CLJS-1190]).

*Background:*
I was investigating the possibility of using reader conditionals to port parts of core.logic to CLJS (specifically: core.logic.fd) and noticed the usage of interfaces as type markers.

The problem with this is that there is no {{definterface}} in CLJS (to my knowledge; attempting to run {{(definterface IFoo)}} fails in a CLJS repl but works in a CLJ repl).

I have started trying to look for a platform-agnostic replacement for the marker interface pattern but wanted to know if there were specific reasons that this pattern was used before diving into actual coding. I also wanted to know if there were already plans to replace this pattern.

*Remediation:*
Ideally a cross-platform method for achieving this could be implemented. If not, then an alternative method could be defined for and used by CLJS at the cost of some performance.

A possible change would be to replace the marker interfaces with marker protocols, and the instances of {{instance?}} with instances of {{satisfies?}}.

The following seem to be equivalent in Clojure:

{{; interfaces}}
{{(definterface IFoo)}}
{{(definterface IBar)}}

{{(deftype T [] IFoo)}}
{{(instance? IFoo (T.)) ; true}}
{{(instance? IBar (T.)) ; false}}

{{; protocols}}
{{(defprotocol IFoo)}}
{{(defprotocol IBar)}}

{{(deftype T [] IFoo)}}
{{(satisfies? IFoo (T.)) ; true}}
{{(satisfies? IBar (T.)) ; false}}

However, the protocol version also works in ClojureScript.

equality of non-unique lvars broken for clojure 1.7

Thu, 25 Jun 2015 19:39:20 +0000

clojure 1.7 changes the interning of strings when creating symbols, as is described here
https://github.com/clojure/clojure/blob/master/changes.md#23-keyword-and-symbol-construction

Therefore, two non-unique lvars with the same name don't have to be equal anymore with the current
Lvar equality method which checks (identical? name (:name o)).

This is causing expresso, which relies on non-unique lvars for the rule engine to fail with clojure 1.7

changing the identical? to a = fixes the issue.

Allow partial matching of keys not existing in a map

Wed, 20 May 2015 18:21:13 +0000

When matching maps, it is sometimes useful to specify a map that doesn't include specific keys.

Eg. to specify a map that doesn't include a :foo key:

(def _! :clojure.core.logic/not-found)
(run* [x]
(featurec x {:foo _!}))

The patch is minimal, and demonstrates the functionality.

walk* exponential in depth of tree terms?

Wed, 28 Jan 2015 05:21:56 +0000

By 'reification' I mean e.g.:

(run 1 [t] (== t <some-constant-to-be-reified>))

Demonstration of exponential performance, using nested vectors ((link: ], [[]], [[[]])...):
https://www.refheap.com/1e30c198d528300fcba9ef24a

Is this expected, or a bug? I'm guessing the former, but hoping the latter. Feel free to close without comment if this is just the way it is. :)

Add non-interleaving version of conde

Sun, 21 Dec 2014 20:13:57 +0000

For validation use cases having depth first search as an option would be very useful.

Guard against arity missmatches between rels, facts and retractions

Thu, 11 Dec 2014 03:31:58 +0000

This patch adds arity checking to relations, facts and retractions so that if a user specifies that a rel "foo" shall be 3-tuple in the def-rel form it will be illegal to add a 4-tuple as a fact to the db. This protects the state of the DB against a class of user errors which would otherwise silently fail through.

This is more a work proposal than anything, as it may well be legitimate to have a variable arity relation. I would just consider such a construct suspect, and this patch supports the way I've approached pldb.

FD logic doesn't always return all solutions

Mon, 20 Oct 2014 19:18:16 +0000

Given the following code

(run* [x11 x12 x13
       x21 x22     x24
       x31     x33 x34
           x42 x43 x44]
      (fd/in x11 x12 x13 x21 x22 x24 x31 x33 x34 x42 x43 x44 (fd/interval 1 9))
      (fd/eq (= (+ x11 (/ x12 x13))   5)
             (= (+ x21 (/ x22   2)) x24)
             (= (+ x31 (/   6 x33)) x34)
             (= (+   4 (/ x42 x43)) x44)
             (= (+ x11 (/ x21 x31))   4)
             (= (* x12 (/ x22   6)) x42)
             (= (+ x13 (-   2 x33)) x43)
             (= (+ (- 5 x24) x34) x44)))

I have {{([1 4 1 3 6 6 1 1 7 4 2 6] [2 6 2 4 6 7 2 1 8 6 3 6])}} as a result.

However, as soon as I change {{(fd/interval 1 9)}} to {{(fd/interval 0 9)}}, the result becomes an empty sequence. However, I expect it to include at least the two aforementioned solutions.

A warning is thrown regarding the redefinition of record? in clojure 1.6.0

Fri, 28 Mar 2014 03:27:45 +0000

Clojure 1.6.0 adds a record? function that has the same implementation as the one in clojure.core.logic. As a result, a warning is shown when the code in the core.logic namespace is evaluated under clojure 1.6.0. Since the two functions have the same implementation, this is purely a cosmetic issue.

Finite Domains - Two consecutive calls to run* return different results

Sun, 23 Feb 2014 00:44:32 +0000

Calling run* twice with the same input may return different results for no apparent reason.
See attachment.

walk* of an empty set overflows the stack

Tue, 31 Dec 2013 10:07:13 +0000

I noticed this issue when asserting a relation with an empty set in it in the new pldb stuff, the minimal case I have is (walk* empty-s #{})

deftest test-34-unify-with-metadata appears incorrect

Mon, 23 Dec 2013 07:10:25 +0000

`
(deftest test-34-unify-with-metadata
(is (run* [q]

        (== q (quote ^:haz-meta-daytuhs (form form form))))
  '((^:haz-meta-daytuhs (form form form)))))

I am not sure what was intended for this, but replacing it with the following causes the test to fail.

`
(deftest test-34-unify-with-metadata
(is (= (run* [q]

           (== q (quote ^:haz-meta-daytuhs (form form form))))
     '((^:haz-meta-daytuhs (form form form))))))

I think the correct version is probably close to that, though.

run macro should take * in addition to n

Tue, 26 Nov 2013 23:28:57 +0000

Extending cljs.core.logic with all of the functionality from clojure.core.logic

Wed, 20 Nov 2013 03:05:40 +0000

Repo I've been working from is here: https://github.com/aamedina/cljs.core.logic

I've followed the code layout in clojure.core.logic pretty much verbatim, compensating for ClojureScript necessities, moved macros into sister .clj files. I have no hard opinions about the best way to organize the macros for each file, the way I do it is just the way I've found easiest, because then you don't have to namespace qualify every syntax quoted form that references a function in the sister .cljs file.

Additionally I ported all of the clojure.core.logic tests with clojurescript.test.

Unified map values are returned as LVar rather than the unified value in ClojureScript

Sun, 29 Sep 2013 15:40:14 +0000

This works correctly in core.logic for clojure:

(run 1 [q]
     (fresh [v]
            (== v 1)
            (== {:x v} q)))

In ClojureScript, I get this though:

({:x <lvar:v_4>})

dcg: def--> ClassCastException

Fri, 23 Aug 2013 20:08:33 +0000

I believe def--> needs to put its lsyms into a vector (as does -->). lsyms is passed to handle-clauses (as the env param), and there is used as a function. This causes an exception since a seq cannot be cast to a function.

compile time occurs check for pattern matching

Tue, 25 Jun 2013 23:32:39 +0000

Claire Alvis correctly pointed out that it's easy to make a mistake when you have many clauses and accidentally use parameter name in a match for that parameter - we could easily do a compile time occurs check for these cases.

Allow tying multiple noms in one binder

Mon, 10 Jun 2013 21:29:53 +0000

I think it may be useful to be able to tie multiple noms in one binder, with or without significant order.

A couple use cases I've thought of so far:

Lambdas in a non-currying language. Here order matters.

(== (list 'fn (ties [x y] (list '+ x y)))
(list 'fn (ties [z w] (list '+ z w)))

My original use case, free/quantified variables in logical formulas. Order doesn't matter (note the second body has its noms swapped).

(== (list '∀ (ties #{x y} (list '= (list '+ x y) (list '+ y x))))
(list '∀ (ties #{z w} (list '= (list '+ w z) (list '+ z w)))))

I have a draft implementation here: https://github.com/tomjack/core.logic/compare/ties

Possible issues with this implementation:
- Is it OK to reextend IWalkTerm to IPersistentSet?
- Should Tie and Ties present a uniform interface? (e.g. (tie? (ties #{x} x)))

Make benchmark suite as easy to run as `lein test`

Thu, 09 May 2013 19:27:59 +0000

`lein benchmark` (or some other non-lein-based incantation) prints a report listing the name of each benchmark and its timing.

Example:

$ lein benchmark
membero 2839
zebra 152738
$ lein benchmark comparison-report {:baseline "benchmark-5.9.2013-1"
                                    :runs 5
                                    :diffs-only true
                                    :threshold 25} ; only consider different if the delta is > 25 ms.
membero +68ms
zebra -122ms
$ lein benchmark {:pretty true}
Thu May 9 11:21:41 PDT 2013

Linux mars 2.6.32-5-amd64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64 GNU/Linux

java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

membero     2839 ms
zebra     152738 ms

I haven't looked for any Clojure benchmarking libs, but ideally this would be a trivial script that automates the repetitive manual task of running benchmark tests. Unlike the test suite, we aren't looking for binary success or failure. Every run will generate unique results, so the script should accommodate a fuzzier comparison.

A "pretty" output that includes system info would be great for bug reports.

Add label goal

Mon, 29 Apr 2013 20:21:19 +0000

This goal should enumerate any fd vars found in a fresh/ground var bound to a sequence. This would avoid some unintuitive behavior that came up on the mailing list:

`
(defne weighted-listo [l w]
([() _] (fd/== w 0))
([[h . t] _]

(fresh [n]
  (fd/in n (fd/interval 0 java.lang.Integer/MAX_VALUE))
  (fd/in h (fd/interval 1 java.lang.Integer/MAX_VALUE))
  (fd/+ h n w)
  (weighted-listo t n))))

StackOverFlowError when walking over set

Tue, 16 Apr 2013 22:55:33 +0000

Walking a Clojure set seems to cause a StackOverFlowError:

`
(run* [?s] (== ?s #{1 2 3}))

(let [s #{1 2 3}] (run* [?s] (== ?s s)))

(run* [?convertedseq ?seq]
(== ?seq #{1 2 3})
(project [?seq]

(== ?convertedseq (vector ?seq))))

`
StackOverflowError

clojure.core.logic/walk*/fn--2722 (logic.clj:216)
clojure.core.logic/eval2927/fn--2928 (logic.clj:956)
clojure.core.logic.protocols/eval1478/fn--1479/G--1469--1486 (protocols.clj:55)
clojure.core.logic/walk* (logic.clj:214)
clojure.core.logic/walk*/fn--2722 (logic.clj:218)
clojure.core.logic/eval2927/fn--2928 (logic.clj:956)
clojure.core.logic.protocols/eval1478/fn--1479/G--1469--1486 (protocols.clj:55)
clojure.core.logic/walk* (logic.clj:214)
clojure.core.logic/walk*/fn--2722 (logic.clj:218)
clojure.core.logic/eval2927/fn--2928 (logic.clj:956)
clojure.core.logic.protocols/eval1478/fn--1479/G--1469--1486 (protocols.clj:55)
clojure.core.logic/walk* (logic.clj:214)

matcha/matchu are not faithful to the semantics of conda/condu

Thu, 04 Apr 2013 20:30:41 +0000

The semantics of conda and condu give special importance to the head of each clause, but the pattern matching macros in core.logic that are built on top of them merge the body into the head. That means that every expression in a body position is considered when deciding which line is chosen, rather than just the expression in the head position. This is because the entire clause is wrapped in a fresh expression to bind the implicitly specified lvars that appear in the pattern.

To illustrate:

`
(matcha ['a]

[['a] u#]
[['a] s#])

;; expands to:

(conda
[(fresh [] (== 'a 'a) u#)]
[(fresh [] (== 'a 'a) s#)])

;; which has a different meaning than:

(conda
[(== 'a 'a) u#]
[(== 'a 'a) s#])

Ideally, we could devise a new system to marry the semantics of conda with pattern matching. At the very least, I think the offending macros should carry a warning in their docstring, stating this semantic difference.

I suspect this would also cause the "Third Commandment" warning to apply to the entire line, rather than just the head/question, but I have not investigated that issue.

Here's an example that demonstrates the difference in meaning:

`
;; This does not succeed, because we commit to the first line,
;; since the question succeeds, but then fail in the body.

(run* [q]
(conda
[(== 'a 'a) u#]
[(== 'a 'a) s#]))

;; => ()

;; This succeeds, because the whole line is used to determine which line to commit to,
;; rather than just the pattern matching clause at the head. So when the first line fails,
;; the second line is tried.

(run* [q]
(matcha ['a]
[['a] u#]
[['a] s#]))

;; => (_0)
`

add mod/rem/abs/min/max

Tue, 02 Apr 2013 18:48:16 +0000

SWI-Prolog's CLP(FD) module has this functionality http://www.swi-prolog.org/man/clpfd.html

Allow unification with sequential in both directions

Sun, 24 Mar 2013 03:10:33 +0000

Currently I can't find a way to enable a custom data type to do unification with sequential objects in both direction. You can use IUnifyTerms to make it work in one direction, but it isn't possible to make it work in the other direction (i.e. when the sequential object is first).

The problem seemes to be in the following code:

`
(defn unify-with-sequential* [u v s]
(cond

(sequential? v)
(if (and (counted? u) (counted? v)
      (not= (count u) (count v)))
  nil
  (loop [u u v v s s]
    (if (seq u)
      (if (seq v)
        (if-let [s (unify s (first u) (first v))]
          (recur (next u) (next v) s)
          nil)
        nil)
      (if (seq v) nil s))))

(lcons? v) (unify-terms v u s)
:else nil))

If the final nil could be replaced with a call to a protocol (IUnifyTermsReversed ???IUnifyWithSequential ???) then I believe it would make this extensible.

tie disequality

Tue, 12 Mar 2013 11:37:39 +0000

`
(deftest test-tie-disequality
(is (= (run* [q]

       (nom/fresh [a b]
         (!= (nom/tie a a) 'hello)))
    '(_0)))

(is (= (run* [q]

       (nom/fresh [a b]
         (!= (nom/tie a a) (nom/tie b b))))
    ())))

Currently, the first causes an error, because IPersistentMap (which gets called because Tie is a record!) assumes that the the other term is also a record (that seems like a bug). If we revert the commit which makes Tie a record, this works.

The other one succeeds, when it should fail. This is regardless of whether Tie is a record or not.

one-shot constraints with multiple rands may run more than once

Mon, 11 Mar 2013 21:10:21 +0000

Here are two examples using fixc:

`
(run* [q]
(fresh [x y]

(fixc [x y]
  (fn [[x y] a _] (!= x 1))
  (fn [[x y] a] (= (walk a x) (walk a y)))
  '...)
(== x y)))

(run* [q]
(fresh [x y c d]

(fixc [x y]
  (fn [[x y] a _] (!= x y))
  (fn [[x y] a] (or (not (lvar? (walk a x))) (not (lvar? (walk a y)))))
  '...)
(== [x y] [[c] [d]])))

The constraint != is reified twice in each example, showing that the fixc constraint indeed ran twice.

Clojure Q&A - Recent questions in core.logic

bug in core.logic with featurec searching for logic variables

core.logic problem

clojure.core.logic/project returning LVar instead of bound value

Memoization in core.logic

Can core.logic reason about sets?

If a map is a coll, why can't conso take its first element?

lein deps and lein classpath fail for current core.logic, where to report?

The order of constraits matters?

EQ conditions which match against a negative result fail to find any results.

*locals* is unbound in some calls to `p->term`

spurious disequality constraints

finite domain uncomplete results

The extension of IDisunifyTerms to LCons calls seq on lcons values. LCons doesn't implement ISeq

An lvar unified with a keyword behaves differently from a keyword

Running rembero returns :- (!= _0 _0)

spec detects error in -inc macro

Document how defn/implicit do with multiple goals does not work

Example of unifier on wiki uses wrong syntax?

binding to a deep nested vector takes too much time

Extending IUnifyTerms doesn't work anymore

Disequality might not eliminate when `(!= (_0 _0))`

LCons fails for inequality

StackOverflowError when logic variable is unified with a set

nafc doesn't work with more complex goals

The docstring of condu is incorrect or at least confusing

Replacing Marker Interfaces

equality of non-unique lvars broken for clojure 1.7

Allow partial matching of keys not existing in a map

walk* exponential in depth of tree terms?

Add non-interleaving version of conde

Guard against arity missmatches between rels, facts and retractions

FD logic doesn't always return all solutions

A warning is thrown regarding the redefinition of record? in clojure 1.6.0

Finite Domains - Two consecutive calls to run* return different results

walk* of an empty set overflows the stack

deftest test-34-unify-with-metadata appears incorrect

run macro should take * in addition to n

Extending cljs.core.logic with all of the functionality from clojure.core.logic

Unified map values are returned as LVar rather than the unified value in ClojureScript

dcg: def--> ClassCastException

compile time occurs check for pattern matching

Allow tying multiple noms in one binder

Make benchmark suite as easy to run as `lein test`

Add label goal

StackOverFlowError when walking over set

matcha/matchu are not faithful to the semantics of conda/condu

add mod/rem/abs/min/max

Allow unification with sequential in both directions

tie disequality

one-shot constraints with multiple rands may run more than once

locals is unbound in some calls to `p->term`