The paper on microKanren [1] is imho the most approachable piece outside the "reasoned schemer" [2]. The thesis on which it is based is also interesting but is a thicker beast. Looking at stuff from the clojure world (clojure.core.logic and this talk [3]) is also interesting imho, especially from a dev perspective. From this point of view I found this talk [4] to be especially enlightening in how to build a database / query engine and concrete applications of MiniKanren / datalog.

[1] https://github.com/jasonhemann/microKanren

[2] https://mitpress.mit.edu/books/reasoned-schemer-second-editi...

[3] https://www.youtube.com/watch?v=irjP8BO1B8Y&ab_channel=Cloju...

[4] https://www.youtube.com/watch?v=y1bVJOAfhKY&t=10s&ab_channel...

If you are struggling to learn the language, you may have better luck learning Prolog first. So you don't deal with the added complexity of it being embedded in a completely unrelated language.

And remember this language for when, after you know Prolog, you start to see how it applies nicely to parts of everything you write, but it completely unsuitable for solving the entirety of almost any problem.

Hi! Which paper were you trying to read?

I'd be happy to try to explain anything you found confusing.

Perhaps this online tutorial would be a helpful start:

https://io.livecode.ch/learn/webyrd/webmk

The main problem is likely that many programmers aren’t familiar with Scheme, or any kind of Lisp. So the material is presented in the context of a host language that itself requires substantial effort to really get used to.

Personally, while I did some Lisp back in university and was reasonably conversant in it at the time, nowadays whenever something nontrivial is presented in Lisp, it’s just too much mental overhead to get back into it, in addition to trying to understand the thing that is being presented.

Terminology like “logic variable” also needs to be explained, if you want to address an audience that isn’t already familiar with logic programming.

One of the hopes is that you can drop in your favorite host language's syntax and get a working implementation. What's your usual language stack these days?

I think the initial surface look makes scheme give a bit of an 'oh crap' response. But since minikanren is actually a small program and scheme doesn't really have syntax the language should be less of a problem than initial concerns might make one think. Grokking the actual logic in any language is going to be the bigger challenge. I guess I am trying to encourage just rolling with lisp if you can, but I totally get the initial reactions toward scheme though.

That's somewhat comforting! But on the other hand, it means also that some of the folk who would be perfectly able to understand the big idea are getting gatekept by just the look of the parentheses, even though host's concrete syntax is of little importance. Which is a darn shame.

Yes, I agree, and understand the point better. Totally a great thing if this can be made accessible to a wider audience and not expect them to do all the work to grok it, especially if there are easy/easier ways to bring it to a wider audience. The parentheses don't usually remain a problem after the initial bump, I had the same issue when I started clojure but after a short while it doesn't continue to be jarring. I think after about 90 minutes it just started to be "natural" perhaps that the wrong word, it was just something that was like ok after a bit and didn't notice too much.

Thanks Will! I think it was the microkanren paper (it's a few years ago now so i'm not 100% sure but seeing it seems familiar). I think I will try the tutorial and see if it helps make it 'click'.

Emails are definitely welcome too! Wherever you get stuck is a failure on the part of the authors.

I found sokuza-kanren [0] to be a wonderful introduction. It starts with the absolute basics and builds into a minimal logic system through a series of well-documented steps.

[0] https://github.com/miniKanren/sokuza-kanren

but one need to learn lisp to read it?..

What's your preferred PL? I suspect we could do a similar build-it-up in that lang too.

I personally code in c++, java and python.

I think python is the most common and simple language with majority of devs would understand for concepts learning, but it is likely too slow for practical applications.

One of the things miniKanren has going for it is that tons of folk have built little embedded implementations in the whatever your favorite host language is. For instance, here's https://web.archive.org/web/20211205175513id_/https://erik-j... a walkthrough of how you'd implement the basics in Python. Comes with an explanation.

I looked at the tutorial and choked at the first step.

First it says "== unifies two terms". Then the first example says "(== x z) (== 3 y)" associates x with z and y with 3. Are "unify" and "associate" the same thing? Why use different words? Why does the association reverse for x and z vs 3 and y? Is it commutative?

Unification is reflexive:

    (== x x) = x for all x

It is commutative:

    (== x y) = (== y x) for all x and y

It is idempotent:

    (== x (== x y)) = (== x y) for all x and y

And it is associative:

    (== x (== y z)) = (== (== x y) z)

It's not transitive, e.g. if we unify pairs (using made up syntax [a, b]) then

    (== [x, 1] [2, y]) = [2, 1]
    (== [2, y] [z, 3]) = [2, 3]
    (== [x, 1] [z, 3]) does not unify (since 1 does not unify with 3)

Thanks for the follow-ups but my comment wasn't really asking what unify and associate mean, I'm questioning the redundant complexity in what is supposed to be the introductory tutorial to the language.

From the submitted page, "The core language, using Scheme as the host language, is described in this short, interactive tutorial."

I think these are great points. Everything should be smooth as butter for an interested reader, and the tutorial should be so approachable and such a page-turner that the curious are hooked on page one and can't put it down.

Really---anything short of that is sub-optimal performance. I think some of it comes from new eyes reading and pointing out room for improvement. The other half is someone having the time to figure out the fix and implement it.

Unification in the context of logic programming is basically like "use these questions and solve for all the unknowns" in algebra, except it's done with logical statements instead of algebraic equations. Searching for something like "unification prolog" (Prolog being the most well-known logic programming language) will probably give helpful material.

For example you could start with two facts like "Fedora is red." and "Cat is green." Then if you ask the system "X is red." it'll tell you "X = fedora". If you ask it to list all the solutions of "X and Y are not the same color." it'll list "X = fedora, Y = cat" and "X = cat, Y = fedora". This process of binding variables to values (or other variables during simplification) is unification.

They are commutative. As to whether unification and association are the same thing... yes, kinda. Unifying two terms kinda means associating them with each other in a database. Though I will say that it would have been better to say 'unifies x and z, as well as y and 3'.

You totally absolutely are smart enough to understand this. Possibly overly so! Happy to jump on a call and answer questions, if useful!

The Reasoned Schemer. Might take a few reads but it's very good. Although you might need some prereqs (e.g. The Little Schemer)