5 ms·

Naga: Datalog-based rules engine in Clojure

87 points by espeed 10y ago

mark_l_watson 10y ago
This looks really good. Make sure to watch the talk that espeed mentions. In the 1980s I spent a fair amount of time hacking Rete networks, mostly in a commercial version of OPS5 I sold for Xerox Lisp Machines, and also a modified version of OPS5 that had meta actions for spawning separate 'worlds, etc. Rete scales well for huge numbers of rules, but not so well for large data sets. I haven't played with Naga yet, but I am curious if that is an issue.
trapperkeeper79 10y ago
I'm curious what the state of the art in rule engines is? I feel this is a neglected topic these days. I'm almost surprised to see new work on the topic.
- taeric 10y ago
  I feel that "business people writing requirements": rules engines::AI: lisp. Right now, it is just a gut feel, though. Basically. I love rules engines. I think I just tried to do too much magic with them on my first encounter.
- tunesmith 10y ago
  I'm curious too - particularly horizontally-scalable distributed rules engines. I realize that might be contradictory since the Rete algorithm scales by throwing memory at it, but what if you want to throw more facts at an expert system than you can reasonably put in one server?
  - deleted 10y ago
    [deleted]
espeed 10y ago
Here's Paula Gearon's (https://github.com/quoll https://github.com/quoll) talk on Naga at Clojure Conj 2016: Production Rules on Databases: https://www.youtube.com/watch?v=8rRzESy0X2k https://www.youtube.com/watch?v=8rRzESy0X2k
hardwaresofton 10y ago
Isn't Prolog the better language for this? Don't get me wrong I love clojure, and one of the best things about dialects of lisp is that they are pretty much always multi-paradigm, but... Pretty sure this is exactly what you would use Prolog for.
- nickik 10y ago
  Its much harder to integrate a new language rather then using a language idiomatic rule engine. Defining everything in Clojure datastructures is a huge asset. Additionally its easy to use Clojure/Java language constructs in combination with the rule engine. In core.logic you can replace the unification alogorithms because its defined abstractly. I don't think this is as easy to do in Prolog.
- eroiusghs 10y ago
  Lisp syntax is so flexible you can pretty much do anything in it - it's nice to get great editor features like REPL integration, Paredit, aggressive-indent-mode etc also when you are specifying your logic. I'm happy to use it :)
- nl 10y ago
  Datalog[1] is a subset of Prolog. Implementing it in Clojure gives you access to the JVM's libraries. [1] https://en.wikipedia.org/wiki/Datalog https://en.wikipedia.org/wiki/Datalog
- tannhaeuser 10y ago
  Exactly. While Datalog is a subset of Prolog, Datomic isn't Datalog. From their tutorial: [:db/add "foo" :db/ident :green] This isn't Prolog syntax at all. Prolog would be assert("foo", ident, green) Franz, Inc. does it as well - calling something Prolog for their Lisp product which it just isn't. I've nothing against Clojure but I wish the functional programming fans wouldn't call their DSLs Prolog or Datalog. If you're using Prolog or Datalog, you're expecting it to be (reasonably) portable accross Prologs, which this isn't at all.
  - nl 10y ago
asciihacker 10y ago
There is also miniKanren, available as core.logic.
- saosebastiao 10y ago
  Seemed like abandonware the last time I tried. Has it been picked up again?
  - znDuff 10y ago
    core.logic has been in continuous commercial use pretty much from its inception, and that continues presently. I'd argue that calling a continuously high rate of change a prerequisite towards usefulness is an attitude which makes more sense in communities where there's little respect for backwards compatibility and thus a high rate of bitrot, ie. Ruby.
    - dkersten 10y ago
      Exactly. I'd rather use something stable that doesn't need much (if any) continuous change.
  - dkersten 10y ago
    There's been maintenance commits regularly (2 days ago, 20 days ago, etc) and the project itself is stable. So while there's been no new features added, I don't see why that would be necessary if it works well as is.

87 points by espeed 10y ago

This looks really good. Make sure to watch the talk that espeed mentions. In the 1980s I spent a fair amount of time hacking Rete networks, mostly in a commercial version of OPS5 I sold for Xerox Lisp Machines, and also a modified version of OPS5 that had meta actions for spawning separate 'worlds, etc. Rete scales well for huge numbers of rules, but not so well for large data sets. I haven't played with Naga yet, but I am curious if that is an issue.

trapperkeeper79 10y ago

I'm curious what the state of the art in rule engines is? I feel this is a neglected topic these days. I'm almost surprised to see new work on the topic.

taeric 10y ago
I feel that "business people writing requirements": rules engines::AI: lisp. Right now, it is just a gut feel, though. Basically. I love rules engines. I think I just tried to do too much magic with them on my first encounter.
tunesmith 10y ago
I'm curious too - particularly horizontally-scalable distributed rules engines. I realize that might be contradictory since the Rete algorithm scales by throwing memory at it, but what if you want to throw more facts at an expert system than you can reasonably put in one server?
- deleted 10y ago
  [deleted]

espeed 10y ago

Here's Paula Gearon's (https://github.com/quoll https://github.com/quoll) talk on Naga at Clojure Conj 2016: Production Rules on Databases: https://www.youtube.com/watch?v=8rRzESy0X2k https://www.youtube.com/watch?v=8rRzESy0X2k

hardwaresofton 10y ago

Isn't Prolog the better language for this? Don't get me wrong I love clojure, and one of the best things about dialects of lisp is that they are pretty much always multi-paradigm, but... Pretty sure this is exactly what you would use Prolog for.

nickik 10y ago
Its much harder to integrate a new language rather then using a language idiomatic rule engine. Defining everything in Clojure datastructures is a huge asset. Additionally its easy to use Clojure/Java language constructs in combination with the rule engine. In core.logic you can replace the unification alogorithms because its defined abstractly. I don't think this is as easy to do in Prolog.
eroiusghs 10y ago
Lisp syntax is so flexible you can pretty much do anything in it - it's nice to get great editor features like REPL integration, Paredit, aggressive-indent-mode etc also when you are specifying your logic. I'm happy to use it :)
nl 10y ago
Datalog[1] is a subset of Prolog. Implementing it in Clojure gives you access to the JVM's libraries. [1] https://en.wikipedia.org/wiki/Datalog https://en.wikipedia.org/wiki/Datalog
tannhaeuser 10y ago
Exactly. While Datalog is a subset of Prolog, Datomic isn't Datalog. From their tutorial: [:db/add "foo" :db/ident :green] This isn't Prolog syntax at all. Prolog would be assert("foo", ident, green) Franz, Inc. does it as well - calling something Prolog for their Lisp product which it just isn't. I've nothing against Clojure but I wish the functional programming fans wouldn't call their DSLs Prolog or Datalog. If you're using Prolog or Datalog, you're expecting it to be (reasonably) portable accross Prologs, which this isn't at all.
- nl 10y ago

asciihacker 10y ago

There is also miniKanren, available as core.logic.

saosebastiao 10y ago
Seemed like abandonware the last time I tried. Has it been picked up again?
- znDuff 10y ago
  core.logic has been in continuous commercial use pretty much from its inception, and that continues presently. I'd argue that calling a continuously high rate of change a prerequisite towards usefulness is an attitude which makes more sense in communities where there's little respect for backwards compatibility and thus a high rate of bitrot, ie. Ruby.
  - dkersten 10y ago
    Exactly. I'd rather use something stable that doesn't need much (if any) continuous change.
- dkersten 10y ago
  There's been maintenance commits regularly (2 days ago, 20 days ago, etc) and the project itself is stable. So while there's been no new features added, I don't see why that would be necessary if it works well as is.