minikanren is an inmutable lang/framework. goals will not be evaluated as logic relations outside run*, this means the goals inside let expression have no effect, only the last goals of let is passed into run*, this means only the last goal from the let body is evaluated. additionally, functional expression will not be evaluated as relations, this means is not posible to use a (functional) for expression, you will need to re-write the for in a relational way ( Disclaimer: I'm not an expert, nor a english native speaker 😄 )

very helpful, thanks!

https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1281 and* will come in handy to transform the seq returned by the for expresion into a goal/relation https://github.com/clojure/core.logic/blob/master/src/main/clojure/clojure/core/logic.clj#L1276 all can combine the goals inside let body into a goal something like

(def m {:a [[1 2 3]
            [2 100 200]]
        :b [[1 2 3]
            [2 3 4]]})

(run* [q]
  (let [result-map (zipmap (keys m) (repeatedly lvar))]
    (all (and* (for [k  (keys m)
                     vs (get m k)]
                 (membero (get result-map k) vs)))
         (fd/distinct (vals result-map))
         (== q result-map))))

just did my own before comparing, works:

(def m {:a [[1 2 3]
            [2 100 200]]
        :b [[1 2 3]
            [2 3 4]]})

(defn member-all [var possibles]
  (and* (map #(membero var %) possibles)))

(let [vars (repeatedly (count (keys m)) lvar)]
  (apply zipmap
         (keys m)
         (run 1 [q]
           (and* (map #(member-all % %2) vars (vals m)))
           (fd/distinct vars)
           (== q vars))))

tho this depends on keys/vals of map always returning in same order

thanks for the help, changed my thinking. i’ll keep at it.

getting better, moved out the let and got rid of the for:

(def m {:a [[1 2 3]
            [2 100 200]]
        :b [[1 2 3]
            [2 3 4]]})

(defn member-all [var possibles]
  (and* (map #(membero var %) possibles)))

(let [result-map (zipmap (keys m) (repeatedly lvar))]
  (run* [q]
    (and* (map (fn [[k vs]] (member-all (get result-map k) vs)) m))
    (distincto (vals result-map))
    (== q result-map)))

this is super slow on large input btw

membero is not fast

It can be hard to give big o measurements of logic programs, because of how abstract they can be, but membero is basically o(n) of the collection

And you are doing it over and over again

maybe the nail doesnt fit the hammer, dont know a better way to phrase it are you planning to run the query backwards?

stupid nail! swing harder.

i don’t know what “run the query backwards” means

relational programs can calculate the inputs given an output, it's like running it backwards

It might speed things up to move distincto up(very non-relational to care about ordering, but it might prune the search tree earlier)

wow @U0NCTKEV8 went from 86s -> 8s with distincto first. I restarted CIDER in between, so shouldn’t be any caching.

I guess the membero is basically growing the search tree exponentially everytime, only for distincto to come along and prune most of it, putting distincto first means most the branches created by membero are immediately pruned

down to 95ms by reducing the multiple memberos per key to one with a set/intersection, good enough

thanks y’all

a great addition to to core.logic would be a clp(set) implementation

btw, I replaced (and* (map with (everyg