4 ms·

Author here: very happy to see some interest in microKanren. It's such a lovely little gem. Has anyone used microKanren as part of a production program?

avmich 4y ago
No, and for me the problem is the following. I (can) have a variant of microKanren embedding in my environment, but the microKanren interface is rather inconvenient to use. miniKanren would be better, but to implement miniKanren in other languages is a bigger problem - actually I hoped to get some help with that using this annotation article.
- ashton314 4y ago
  > but the microKanren interface is rather inconvenient to use What specifically would make it easier? I'm not that familiar with miniKanren. Is it stuff covered by the convenience macros from the paper?
  - avmich 4y ago
    Good question. I suspect the problem is in that the goals are expressed as functions in microKanren, and it's hard to figure out how to represent what is needed to get as such functions. It looks like Prolog approach is more understandable - there are symbols and rules; not sure if Prolog would be easier to embed in, say, Java and switch between Java objects and Prolog rules. microKanren is practically by definition for embeddability - so it's this aspect which for me present a problem.
lukev 4y ago
Clojure's core.logic (a Clojure implementation of miniKanren) definitely gets some use in production.
rscho 4y ago
Not really production, but probably THE most impressive biomedicine research work I've seen (and I'm an academic MD): https://github.com/webyrd/mediKanren https://github.com/webyrd/mediKanren This is a FOL theorem prover that uses medical research articles as terms. They use it to do genetics and drug repurposing metaresearch. It's like the wet dream of all the biomed machine learning fanboys out there, except that: 1. it's not machine learning and 2. it really works
- YeGoblynQueenne 4y ago
  Note you can do machine learning of logic programs. My PhD research: https://github.com/stassa/louise https://github.com/stassa/louise In which case it _is_ machine learning and it still really works :D
  - rscho 4y ago
    Yeah, I wanted to try your system on the same database as they're using for medikanren. I got stuck bc loading the whole thing into the prolog fact database was too huge. Perhaps I should retry by querying the SQL database from prolog.
    - YeGoblynQueenne 4y ago
      Yes, I've seen this before. I'd suggest partitioning the database into parts that fit comfortably in memory and processing each separately, then simply combininig the learned programs into one. You can do this with Prolog because you can keep adding clauses to a program, or removing them from it, for as long as you want, and the program won't (necessarily) break, it will just become more specialised, or generalised (respectively). John McCarthy called that "elaboration tolerance". To, er, elaborate a bit on this, a logic program is a set of clauses interpreted as a conjunction (even if they look like alternatives!) so that the program as a whole has a set of "facts" it entails, but without any other assumptions about the relation between the clauses with each other. If you add clauses, your program entails more facts. If you remove clauses, it entails fewer facts. With negation-as-failure, the relation is non-monotonic, but it's still the same idea. This is what makes it possible to learn Prolog programs from examples, in the first place. With Louise in particular, because it builds up programs clause-by-clause, you can even train it with a single example at a time. It used to be it was limited in its one-shot learning capabilities but it's much better now. In fact, if you're doing any preliminary work with Louise, you really want to start by training it on a handful of examples at a time, so you can best figure out the right configuration to use to learn the kind of program you want it to learn. Otherwise, if you throw the entire database at it, even if it fits into memory, you'll get so much in the output that it will just be overwhelming. ILP and Louise work a bit differently than ordinary machine learning. You want to go slowly, processing small data in small batches, otherwise you get a firehose of clauses in the face and drown. It's the tradeoff you get for being able to inspect the learned "model": there's still a lot of it and you have to develop strategies to deal with its complexity. Hope that makes sense? Please do get in touch if you need help with Louise. Or anything ILP!

avmich 4y ago

No, and for me the problem is the following. I (can) have a variant of microKanren embedding in my environment, but the microKanren interface is rather inconvenient to use. miniKanren would be better, but to implement miniKanren in other languages is a bigger problem - actually I hoped to get some help with that using this annotation article.

ashton314 4y ago
> but the microKanren interface is rather inconvenient to use What specifically would make it easier? I'm not that familiar with miniKanren. Is it stuff covered by the convenience macros from the paper?
- avmich 4y ago
  Good question. I suspect the problem is in that the goals are expressed as functions in microKanren, and it's hard to figure out how to represent what is needed to get as such functions. It looks like Prolog approach is more understandable - there are symbols and rules; not sure if Prolog would be easier to embed in, say, Java and switch between Java objects and Prolog rules. microKanren is practically by definition for embeddability - so it's this aspect which for me present a problem.

lukev 4y ago

Clojure's core.logic (a Clojure implementation of miniKanren) definitely gets some use in production.

rscho 4y ago

Not really production, but probably THE most impressive biomedicine research work I've seen (and I'm an academic MD): https://github.com/webyrd/mediKanren https://github.com/webyrd/mediKanren This is a FOL theorem prover that uses medical research articles as terms. They use it to do genetics and drug repurposing metaresearch. It's like the wet dream of all the biomed machine learning fanboys out there, except that: 1. it's not machine learning and 2. it really works

YeGoblynQueenne 4y ago
Note you can do machine learning of logic programs. My PhD research: https://github.com/stassa/louise https://github.com/stassa/louise In which case it _is_ machine learning and it still really works :D
- rscho 4y ago
  Yeah, I wanted to try your system on the same database as they're using for medikanren. I got stuck bc loading the whole thing into the prolog fact database was too huge. Perhaps I should retry by querying the SQL database from prolog.
  - YeGoblynQueenne 4y ago
    Yes, I've seen this before. I'd suggest partitioning the database into parts that fit comfortably in memory and processing each separately, then simply combininig the learned programs into one. You can do this with Prolog because you can keep adding clauses to a program, or removing them from it, for as long as you want, and the program won't (necessarily) break, it will just become more specialised, or generalised (respectively). John McCarthy called that "elaboration tolerance". To, er, elaborate a bit on this, a logic program is a set of clauses interpreted as a conjunction (even if they look like alternatives!) so that the program as a whole has a set of "facts" it entails, but without any other assumptions about the relation between the clauses with each other. If you add clauses, your program entails more facts. If you remove clauses, it entails fewer facts. With negation-as-failure, the relation is non-monotonic, but it's still the same idea. This is what makes it possible to learn Prolog programs from examples, in the first place. With Louise in particular, because it builds up programs clause-by-clause, you can even train it with a single example at a time. It used to be it was limited in its one-shot learning capabilities but it's much better now. In fact, if you're doing any preliminary work with Louise, you really want to start by training it on a handful of examples at a time, so you can best figure out the right configuration to use to learn the kind of program you want it to learn. Otherwise, if you throw the entire database at it, even if it fits into memory, you'll get so much in the output that it will just be overwhelming. ILP and Louise work a bit differently than ordinary machine learning. You want to go slowly, processing small data in small batches, otherwise you get a firehose of clauses in the face and drown. It's the tradeoff you get for being able to inspect the learned "model": there's still a lot of it and you have to develop strategies to deal with its complexity. Hope that makes sense? Please do get in touch if you need help with Louise. Or anything ILP!