Naga: Datalog-based rules engine in Clojure | Hacker News Reader

Naga: Datalog-based rules engine in Clojure

github.com

87 pointsespeed23 comments

Here's Paula Gearon's (https://github.com/quoll) talk on Naga at Clojure Conj 2016:

Production Rules on Databases: https://www.youtube.com/watch?v=8rRzESy0X2k

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.

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.

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.

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?

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.

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.

'Prolog' in Lisp exits for decades. During the 80s several Prolog implementation had been developed for research systems and also for commercial systems. Many used an s-expression syntax for Prolog, but some could also read 'Edinburgh' syntax.

Most of the time these 'Prolog' implementations are not as powerful/complete like a typical modern Prolog implementation.

LispWorks for example has an expert system development extension with an integrated Prolog.

http://www.lispworks.com/documentation/lw70/KW-M/html/kwprol...

It also offers to read Edinburgh syntax and also has a command line interface for this syntax.

http://www.lispworks.com/documentation/lw70/KW-M/html/kwprol...

But it still is far from ISO Prolog compatible.

> 'Prolog' in Lisp exits for decades.

I sure hope so ;)

Also it's clear ISO Prolog isn't universally embraced (http://www.cs.unipr.it/~bagnara/Papers/Abstracts/ALPN99a) since most popular Prolog implementations based on WAM were started way earlier.

I guess there are worse things Prolog had to suffer; namely, Perl insensitively took away the .pl file suffix and made it its own.

Where are you seeing that it uses Datomic? The linked page says:

Datalog based rules engine and The language being implemented is called "Pabu" and it strongly resembles Prolog.

There doesn't seem to be much documentation for this, but the examples look like this:

    sibling(fred, barney).
    parent(fred, mary).
    sibling(mary, george).
    gender(george, male).
    /* Using the OWL namespace to describe the sibling property */
    owl:SymmetricProperty(sibling).

See [1]

It's been a while since I did Prolog, but that looks pretty familiar (and like your example)

[1] https://github.com/threatgrid/naga/blob/master/pabu/family-2...

You're right. I was referring to Datomic because it was linked to from https://github.com/quoll.

Mind you, Prolog (ISO/IEC 13211-1) has very specific requirements with respect to exceptions, arithmetic, operator-precedence parsing and resolution/negation-as-failure/extra-logical features, which I see often glossed over when people call something Prolog in a roundabout way.

Hence why they claim to be Datalog.

It's a longish talk, but the syntactic difference between systems like Datomic and traditional Datalog systems is discussed in the video mentioned above: https://www.youtube.com/watch?v=8rRzESy0X2k

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.

My problem with Prolog is that its a useful paradigm for a subset of any program, but not for the entire thing.

I really like Clojure's core.logic approach: use core.logic (which works like prolog) for the bits where it makes sense and use Clojure for the bits where it doesn't. That is, the right tool for the job.

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

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

Prolog can't scale over large data sets. That's why Datalog was invented. So Prolog has significantly greater capabilities, but Datalog scales better. Your use case determines which one is more appropriate for you.

There is also miniKanren, available as core.logic.

Seemed like abandonware the last time I tried. Has it been picked up again?

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.

Exactly. I'd rather use something stable that doesn't need much (if any) continuous change.

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.

Reply on news.ycombinator.com