FD constraints are always forced at the end so this is not a blocker.

fixed

The macros 'fnm' (and fn[eau]) use the optional argument :tabled after the argument list. Is it ok?

tabling passed as an option is OK with me.

Also could we get tests? Thanks much!

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?

This looks good. Two things:

• squashed patch
• tabled anonymous goal patch

we're almost there

i do not understand what you mean. you prefer a separate patch for tabled anonymous goal?

Sorry typo, I meant a test for the tabled anonymous goal. Thanks!

thanks, i'll do it asap.

Squashed Patch with tests for the fn[e] macros, normal and tabled.

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.

Thanks will take a look!

Clojure 1.5.1, both 0.8.3 and 0.8.4--994a7a3

Running on a 1GB VM.

Sounds like an excellent enhancement to me. Patch welcome for this.

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

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

The attached patch does not work, many tests fail.

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

I added those initial definitions when I thought "groundedness" was the operative word, so they aren't directly relevant.

Thanks, I'll happily accept docstring patches.

This patch changes the docstrings for lvaro and nonlvaro to be more accurate. This is a fix for LOGIC-131.

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

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.

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

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

core.locic 0.8.3

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

core.logic 0.8.3
Clojure 1.5

core.logic no longer supports unification of sets so you're just seeing an error as result of a complete lack of support. I'm not against supporting basic unification of completely grounded sets, as then we only need to test for equality, but I'm inclined to make the system throw if any logic vars appear in the sets.

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)

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!

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.

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

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

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.

OK, the CA has arrived and been processed.

http://clojure.org/contributing

• Jiri Marsik (jirkamarsik)

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

Thanks!

For reference:

The Third Commandment

If prior to determining the question of a conda (or condu) line a variable is fresh, it must remain fresh in the question of that line.

From The Reasoned Schemer.

Good catch I need to think about this one.

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.

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.

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.

fixed http://github.com/clojure/core.logic/commit/52eec3b04c2b785c84bed81671db80c2163c4967

I'm assume it's undesirable for your datatype to implement ISequential?

It's undesirable because an expression can be a leaf node as well:

(+ 3 X) ;; OK as sequential
7 ;; definitely not sequential!

Hence making Expression implement ISequential would be problematic and break all kinds of contracts.....

Trying to unify the leaf node with a sequential object should fail of course, but that's logic I need to implement myself (I think??)

I'm still not following as there's some context about your use case that I'm missing. Do you have a concrete core.logic example that you should think should work?

Sure, here is my test case:

(let [ex1 (ex [+ 1 X])]  ;; an expression containing (+ 1 X) 
  (is (= [(ex X)] (run* [q] (fresh [op p] (== [op p q] ex1)))))  ;; fails
  (is (= [(ex X)] (run* [q] (fresh [op p] (== ex1 [op p q])))))  ;; OK
)

The first case fails (because of unify-with-sequential* returning nil as above). The second case is OK because it goes through my own implementation of IUnifyTerms. I may be wrong, but I don't think I can make it work without a change in core.logic itself.

We used to support unifying in both directions but it made for a large number of protocols that had to be implemented. Recently I've been thinking it may be useful to provide coercion protocols, something like ICoerceToSequential.

I think it is necessary to be able to support unifying in both directions somehow if custom data structures are ever going to be first-class citizens in core.logic?

I see how you could achieve this with ICoerceToSequential however so that might be a good solution. We do something a bit similar in core.matrix (to handle coercions between different back-end matrix implementations).

custom data structures are already first class. Whether we should allow overloading unification of custom types with core Clojure interfaces/protocols/types is another matter entirely.

And sorry for the confusion. It's not clear to me why you want sequential to work, from your examples it appears that you have a proper expression type, what advantage is there for you to unify with sequential?

I think it may be important if you have "sequence-like" data structures that aren't precisely sequential? but are conceptually equivalent to sequences. My custom Expression type is one example, and for interop reasons things like java.util.ArrayList spring to mind.

As it happens, I've switched back to using regular lists for the moment so the issue isn't a blocker for me. But it may still be worth thinking about.

Couple of advantages of doing this kind of unification would appear to be:
a) notational - you can use regular Clojure lists and vectors for unifying with something sequence-like
b) efficiency - avoid constructing a new custom object when it isn't needed (though the cost is probably too trivial to bother about in most cases....)

Of course, you may decide it is simpler and purer to avoid these complications, which is fine. But it seems a shame to have all the nice extensible protocols, and not quite be able to fully extend the functionality to custom types....

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.

Thanks, that is good to know.

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

For the first example I see the following as a result on master:

((_0 :- (!= (_1 1))))

Is this what you're seeing? As x isn't even part of the answer I wonder if we should show these constraints?

I changed the reifier by setifying the set of constraints, hence you get only one result now. So my illustration is now out-of-date but the problem remains. It's a separate issue to filter out irrelevant constraints, and I agree it should be done (I try to do it for the nominal constraints).

It looks this issue still exists even if you swap the matcha with matche

I think the overflow is occurring during reification.

I was getting this error when returning a result from run, but now that I'm using the same value as the input to another goal there is no overflow.

If you replace q in the foo call with a fresh variable, it will not overflow.

This works for me on master. Can you give me more specifics about your setup so I can try to recreate? I'm on OS X 10.8 running JDK 7 64bit.

I don't see the issue anymore, but I believe I was using Java 1.6 when I reported it and now I am using:

$ java -version
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

OK, thanks for the quick response, I'll double check how things look under 1.6.

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

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

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

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.

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

Basic usage has since been added to README.md

Currently dead code so this is not a blocker.

all

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

I'm surprised that this doesn't already work. We have support for unifying expressions in the pattern already. Look at line 1230 in tests.clj in the master branch.

So this should just work, no need to explicitly support macros as far as I can tell. If it's not working, then there's a bug.

At least on 0.7.5, matching against a macro gives a runtime error:

Exception in thread "main" java.lang.ClassCastException: clojure.core.logic.LVar cannot be cast to clojure.lang.IFn
	at rl.core$glyph_$fn__123$fn__144$fn__165$fn__166$_inc__167$fn__168.invoke(core.clj:61)
	at clojure.core.logic.Substitutions.bind(logic.clj:211)
	at rl.core$glyph_$fn__123$fn__144$fn__165$fn__166$_inc__167.invoke(core.clj:58)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__890$fn__891.invoke(logic.clj:828)

Using a fn instead of a macro gives the same:

Exception in thread "main" java.lang.ClassCastException: clojure.core.logic.LVar cannot be cast to clojure.lang.IFn
	at rl.core$drawable_$fn__235$fn__248$fn__249$_inc__250$fn__251.invoke(core.clj:67)
	at clojure.core.logic.Substitutions.bind(logic.clj:211)
	at rl.core$drawable_$fn__235$fn__248$fn__249$_inc__250.invoke(core.clj:65)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__894$_inc__895.invoke(logic.clj:826)
	at clojure.core.logic$fn__1056$_inc__1057.invoke(logic.clj:1160)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__898$_inc__899.invoke(logic.clj:823)
	at clojure.core.logic$fn__890$fn__891.invoke(logic.clj:828)

Here's (glyph-) for reference (don't mind all the extra [], I have a weird key/value thing because of some conveniences for maintaining fact identity in a temporal database):

(defna glyph- [Key Val]
	([[Thing] [Glyph]] (thing- [Thing]) (on-fire_ *turn* [Thing]) (== Glyph \δ))
	([[Thing] [Glyph]] (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (glyph- [Type] [Glyph])))
	([[(type-enum :player)] [Glyph]] (== Glyph \@))
	([[(type-enum :dragon)] [Glyph]] (== Glyph \D))
	([[Type] [Glyph]] (== Glyph \?)))

and type-enum as a macro:

(defmacro type-enum [v] `[:enum :type ~v])

and as a fn:

(defn type-enum [v] [:enum :type ~v])

I'll mess around and see if my example works in HEAD.

Same exception with this test case in HEAD (sorry for all the facts):

(defrel thing- [Thing])
(defrel type- [Thing] [Type])
(fact thing- [0])
(fact thing- [1])
(fact thing- [2])
(fact type- [0] [:player])
(fact type- [1] [:dragon])
(fact type- [2] [:pig])
(defn type-enum [t] [:type t])
(defna drawable- [Key]
  ([[Thing]] (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (drawable- [Type])))
  ([[(type-enum :player)]] succeed)
  ([[(type-enum :dragon)]] succeed))

(deftest do-fns-work
	(is (= (run* [q] (drawable- [q])) '(0 1))))

Now that I look at it, I may be expecting a wrong-format return value, but the point is that I don't even get that far.

Using the REPL, I checked out how (defna drawable- . . .) expands (tidied up slightly):

(def drawable- (clojure.core/fn ([Key] 
  (clojure.core.logic/conda 
	  ((clojure.core.logic/fresh [Thing] (clojure.core.logic/== [Thing] Key) (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (drawable- [Type])))) 
		((clojure.core.logic/fresh [type-enum] 
		  (clojure.core.logic/== [(type-enum :player)] Key) succeed))
		((clojure.core.logic/fresh [type-enum] 
		  (clojure.core.logic/== [(type-enum :dragon)] Key) succeed))))))

Note the (clojure.core.logic/fresh [type-enum] . . .) forms, which are exactly what I would not want to see in this case.

I'm not really sure why this doesn't work here yet works for the matche test case.

[(type-enum :dragon)]

This pattern make it seem like you want to match:

[[:type :dragon]]

Note extra level of brackets here. Is this the case?

Even so I agree that the expansion doesn't look quite right. We should never descend into a seq form like that.

Yes, that's exactly the desired outcome in this case--a tagged value in my naive interpretation. Is the reason it fails whereas the test on :1230 doesn't the fact that it's producing a vector and not a list? Changing the fn to return a list instead of a vector didn't seem to help.

My patch, fwiw, doesn't exhibit that behavior (at least for macros, haven't tested it with fns).

What I mean is don't you want the following instead?

(defna drawable- [Key]
  ([[Thing]] (thing- [Thing]) (fresh [Type] (type- [Thing] [Type]) (drawable- [Type])))
  ([(type-enum :player)] succeed)
  ([(type-enum :dragon)] succeed))

Note that I removed a layer of square brackets.

Nope! I actually want both. I'm doing some temporal logic stuff and I wanted some conveniences for "updating" a fluent, so I wanted to distinguish between the "key part" and the "value part" of the arguments. It looks silly for facts with no "value part", but it lets me write procedures and fns something like this:

(defrel heldo Time Fluent)
(defrel ¬heldo Time Fluent)
(declare fluent-obtainedo) ; most recent 'held' not terminated by a '¬held', or fail
(defn alter-fluent [Time Rel Key NewVal]
  ;todo: error check, ensure old != new, old obtains, new does not obtain
  (doseq [old-val (run* [old-val] (fluent-obtainedo Time [Rel Key old-val]))]
    (fact ¬heldo Time [Rel Key old-val]))
  (fact heldo Time [Rel Key NewVal]))
. . .
(fact heldo 0 ['pos [0] [0 0]])
. . .
(alter-fluent 1 'pos [0] [1 1])

And I write all the non-temporal fluents that way too for consistency and to help prevent mistakes.

I'll try to give a closer look at this issue over the weekend.

We're thinking about a more general solution here: http://github.com/clojure/core.logic/wiki/Better-syntax-support

[org.clojure/clojure "1.4.0"]
[org.clojure/core.logic "0.8.0-beta2"]

I'm assuming this is referring the ClojureScript version of core.logic?

This is not a bug. Goals do not delay evaluation in this way.

Can you reformat the patch w/ git so it has the proper attribution information? Thanks!

New patch with attribution info. Sorry about super long turn around time, in the future I should be much faster.

This patch solved the exact same problem for me aswell.

Cheers...

I've yet to hear a good rationale for this patch. defrel has the same semantics as def and should only exist at the top level. If someone puts more though into what defining a rel dynamically should look like I will consider it.

I only implemented this so I could delete relation state. There's probably a better way to do this though.

Indeed, a make-rel function would be optimal, then you can def it (or store it somewhere else) at your leisure.

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.

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

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

There's far too much context here. Do you have a minimal case? Thanks much!

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)

I tightened up the fail case https://github.com/m0smith/LogicPuzzles/blob/master/src/logicpuzzles/corefail.clj . Is that enough?

Thanks can you add the failing code to the ticket as an attachment? Thanks.

corefail.clj exhibits the error

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

patch LOGIC-118.diff fixes this issue. I'm not sure if it does so correctly.

It's seem to me that this should be corrected in prep*? It looks like the issue is that prep* only handles seqs and not collections in general.

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.

Patch applied from LOGIC-122

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

patch applied from LOGIC-122

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

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

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

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?

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!

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

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

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

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

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.

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

quick fix in https://github.com/clojure/core.logic/commit/8af0f45f8d1cb515ec7a00e5acd751562a31bb37

for actually doing != modulo alpha equivalence requires the opposite of nom/hash.

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

Closed wrong ticket

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.

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

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

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

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

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

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.

Makes sense will apply later today.

I am going to apply the refactoring to master.

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

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

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

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.

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.

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.

Not a bug.

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

I'm working on understanding the answers given for this StackOverflow question:

http://stackoverflow.com/questions/7647758/prolog-findall-implementation

For discussion — Initial working patch supporting nested version of 'run-a/'run-a*. Binding symbols must match existing lvars with which vectors of all returned values will be unified.

Should we provide wrappers that emulate each of bagof, setof and findall?

I'm still not sold on the current names run-a/run-a*. "a" is really an internal implementation detail. Expect a revised patch with better names when I think of them (any ideas?).

Yes please. Yeah I don't think the names of run-a/etc are critical - implementation details for now until we really understand the implications and it gets some use.

I'm considering simply making run/run* conditionalized on the first argument, using the nesting form if we are being called with a substitution map as the first argument.

My current understanding of bagof and findall makes me think they're not worth implementing beyond the nesting run functionality.

I'm still thinking about setof which is quite useful and will want help from the infrastructure to be fully efficient.

I'll submit a new patch after Thanksgiving.

Excellent, thanks much.

I have not forgotten, I've just gotten swamped.

There's a small chance I'll get to this before Christmas, otherwise, it's after the new year.

After a car accident, travel to London and Morocco, getting caught up at work and getting caught up on the apparently very busy stream of core.logic activity (great work!), I'm back on this.

I found some bugs in my implementation after porting the patch forwards and realized these issues highlighted my sloppy understanding of some of the semantics I had created.

I'm fairly convinced now that we don't want to name this after run or run*. It's too much of a strain to try to make it mean the same thing in a nested context.

The current mechanism is still not quite a match for findall/bagof/setof, however, so I'm seeing what a good fit would be. I'll post meaningful thoughts for review as I have them.

Glad to hear you're OK! No worries, will take a patch whenever you get around to one.

Can we get a squashed patch please? Thanks!

Update with squashed patch.

Sorry about that---exported a bad squashed patch earlier. This latest one passes all tests.

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

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

Does this work for you?

yep, thanks

fixed

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.

Yes the project.clj is for development purposes only. It's not used to resolve dependencies.

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.

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

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

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

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

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.

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

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

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?

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

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=>"

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.

Thanks for the update, closing this one!

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?

Will need to think about this some more.

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

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.

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.

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

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

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

I cannot recreate on my machine but should try a large N & wait and see.

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

Well it is possible to disable occurs-check. Why can't we just use the existing occurs-check fn to do this work?

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

Ok, makes sense. Can we get a new patch using master. This one doesn't apply anymore. Thanks!

logic-100-rebase.diff is a new patch against master. I also added the extra tests discussed above.

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

logic-101.diff has workaround + test.

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

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

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

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.

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.

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.

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

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

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.

Not a bug

0.7.5 or 0.8-alpha

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.

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

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