Clojure JIRA

[LOGIC-138] Allow tying multiple noms in one binder

Mon, 10 Jun 2013 16:07:23 -0500

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)))

[LOGIC-130] StackOverFlowError when walking over set

Tue, 16 Apr 2013 17:28:27 -0500

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)

[LOGIC-123] Allow unification with sequential in both directions

Tue, 26 Mar 2013 01:07:40 -0500

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.

[LOGIC-87] Decomplect the narrowing of the constraint space from the search order

Fri, 28 Dec 2012 00:41:40 -0600

From a high-level point of view a constraint solver takes a constraint space, generates a tree of narrowings of the space and runs some search algorithm on the tree. Core.logic complects the generation of this tree and the search algorithm by representing the search space as a lazy stream of the leaves of the tree. By explicitly representing the search tree we get new search algorithms, optional fair conjunction and parallel search via fork-join.

More detail: http://scattered-thoughts.net/blog/2012/12/19/search-trees-and-core-dot-logic/

Github fork: https://github.com/clojure/core.logic/pull/13

Attached is a cleaned-up patch against d68e3400472c5f745e4c13d64433459e11ba4871

[LOGIC-86] make `defc` more useful

Sun, 17 Mar 2013 18:30:51 -0500

As we start adding more constraints it's becoming clear we really want to have to specify less boiler plate. Instead of:

(defn -treec
  ([x fc cform] (-treec x fc cform nil))
  ([x fc cform _id]
     (reify
       clojure.lang.IFn
       (invoke [this a]
         (let [x (walk a x)]
           (if (tree-term? x)
             ((composeg
               (constrain-tree x
                 (fn [t a] ((treec t fc cform) a)))
               (remcg this)) a)
             ((composeg
               (fc x)
               (remcg this)) a))))
       IConstraintId
       (id [this] _id)
       IWithConstraintId
       (with-id [this _id]
         (-treec x fc cform _id))
       IConstraintOp
       (rator [_] `treec)
       (rands [_] [x])
       IReifiableConstraint
       (reifyc [_ v r a]
         (let [x (walk* r x)]
           `(treec ~x ~cform)))
       IRelevant
       (-relevant? [_ a] true)
       IRunnable
       (runnable? [_ a]
         (not (lvar? (walk a x))))
       IConstraintWatchedStores
       (watched-stores [this] #{::subst}))))

(defn treec [x fc cform]
  (cgoal (-treec x fc cform)))

We should be able to write just:

(defc treec [x fc cform]
  clojure.lang.IFn
  (invoke [this a]
    (let [x (walk a x)]
      (if (tree-term? x)
        ((composeg
          (constrain-tree x
            (fn [t a] ((treec t fc cform) a)))
          (remcg this)) a)
        ((composeg
          (fc x)
          (remcg this)) a))))
  IConstraintRands
  (rands [_] [x])
  IReifiableConstraint
  (reifyc [_ v r a]
    (let [x (walk* r x)]
      `(treec ~x ~cform))))

`defc` should intelligently fill in the details.

[LOGIC-70] support for defaults in the simple unifier

Sun, 17 Mar 2013 18:49:10 -0500

There should be a way to specify a logic var with default values. If it is not unified with something it should unify with the default provided value.

[LOGIC-48] fd/in should provide a default domain if none specified

Fri, 17 May 2013 00:57:46 -0500

This domain should probably be (interval 0 Long/MAX_VALUE). In order for this to work this means we should probably accept passing in the vars to assigned domains as a seqable. It would be easy to accept the current way and this new way since if the first arg is not a symbol then the new behavior is being requested.

(fd/in [x y])
(fd/in [x y z] (interval 0 10))

[LOGIC-44] ex* could expand macros in patterns

Sun, 17 Mar 2013 19:05:17 -0500

So, tagged data structures are probably interesting in a relational context. Say you have a relation with some default logic about dogs:

(defna friendlyo [Dog-Or-Breed]
    ([:Spot] succeed)
    ([:Spike] fail)
    ([Other-Dog] (fresh [Breed] (dog-breed Other-Dog Breed) (friendlyo Breed)))
    ([(breed :miniature-dachshund)] fail)
    ([(breed :golden-retriever)] succeed)
    ;. . .)

Assume there's a (defmacro breed [t] `[:breed ~t]).

That's nicer than having to drop [:breed :golden-retriever] in there or whatever, since it's compile-time-checkable, less error-prone, reduces duplication, etc.

This little patch makes ex* expand macros in patterns so it doesn't treat e.g. (breed :golden-retriever) as introducing a new LVar called "breed". Test also provided.

[LOGIC-43] LVar should print readably

Thu, 5 Jul 2012 20:20:40 -0500

Currently LVar objects print the same as symbols; they should either print as an unreadable form, or in a way that the reader can read them back in and get an LVar. Attached patch causes them to be read in as LVars.

However, (read-string (pr-str lv)) does not compare as equal to lv, because the implementation of .equals relies on their string :name objects being identical? - which they will not be, if one LVar was created by the lvar function, which uses str, and the other created by read-string, which uses String/intern.

It seems plausible to say that LVars can't be compared for equality after sending them through strings, but that's awkward and unpleasant. We could instead define LVars to compare their names with = rather than with identical?, but David expressed concern about the performance implications of that change.

[LOGIC-35] Core.logic equivalent of multimethods

Fri, 28 Dec 2012 00:48:09 -0600

I need to define predicates to which I can later (and from other namespaces) attach further clauses (so not just facts). I couldn't find any such functionality in the source. Due to the extensive use of macros, hacking such a system onto core.logic from the outside is extremely difficult, if not impossible (to me at least).

I'd love to implement this myself too, if given an OK and rough direction.

[LOGIC-28] defrel cannot be called inside function

Sun, 17 Mar 2013 18:55:08 -0500

defrel cannot be called inside function

[LOGIC-26] Generate a better error when adding facts for arities that do not exist

Sun, 17 Mar 2013 18:54:33 -0500

Generate a better error when adding facts for arities that do not exist