Clojurians Log v2

My fear with asserting more data is that it doesn’t halt the reasoning. From falsehood anything follows; so it’d be useful to terminate the reasoning rather than continue computing the closure over something inconsistent

I guess I could probably raise an exception by binding to a special predicate backed by a function that raises an exception

Well, that’s why I was thinking that an error predicate could be detected at line 125 in the engine, and thrown at that point

Actually, I think I did this in Mulgara rules engine? :thinking_face:

oh sorry I missed that bit of the message

Anyway… if you’d like that, then put in a ticket. I’d be happy to look at doing it

Trying desperately to wrap up Asami 2.0.0-alpha right now. I’m just about there

So I’m not looking at anything else until next week 🙂

Yeah I think it would be useful; especially if it could capture the context (bindings) to explain the error

It’s ok non of this is urgent by any means… just noodling around 🙂

Looks like to implement eq-diff2 I’ll need to implement a ternary predicate:

I think something like this is the natural implementation (untested because naga currently supports unary/binary predicates).

ta:compare(L,X,Y) :- krule:inList(L,X),
                     rdf:rest(L,L2),
                     krule:inList(L2,Y).

ta:error(eq-diff2) :- owl:AllDifferent(XXX),
                      owl:members(XXX,List),
                      ta:compare(List,XXX,ZZZ),
                      owl:sameAs(XXX,ZZZ).

I’ve been looking at different syntaxes for rules, to make multi-arity predicates, lists, and entity structures more natural. It can all be translated into triple patterns, but the resulting rules are difficult for people to read and write

e.g. X is in a list: [… X …] X starts a list: [X …] X is at the end of a list: [… X] X is the third item in a list: [_ _ X …] X is the second last item in a list: [… X _]

Maybe

Actually, the Clojure way would be to ignore anything at the end of a matching pattern in a seq, so trailing dots would be redundant

yeah something clojurey makes sense for naga… If you were planning to support it in pabu, you’d do well to lift the list syntax from datalogs big daddy, prolog! 🙂 e.g. for recursively finding members in a list you’d write:

member(X,[X|_]).
member(X,[_|TAIL]) :- member(X,TAIL).

True

For Pabu, this makes sense. It was supposed to be a Datalog after all

But I have a need to create a new language that is based around entities

Yeah - I agree with this btw. Also I think not having some of these features prevents you from creating useful abstractions… i.e. I can’t reuse ta:compare, I have to inline it everywhere.

Something like:

{:type "CourseOfAction"
 :action "block"
 :observable O}
:-
{:type "sighting"
 :observables [... {:type T, :value V} ...]},
{:type "verdict"
 :disposition "Malicious"
 :observable {:db/id O, :type T, :value V}}

That’s a pseudocode version of something we were looking at. It’s our private vocabulary for expressing some public data models, so I think it’s relatively safe to post as an example

Writing it in Datalog syntax is awful, since we’re having to express the data structures in triple patterns, and it’s necessary to know the syntax and structure for expressing entities. That’s more than users should need to know

Also, if I’m moving from Datalog, then I could use different syntax for variables. e.g. ?t instead of T

Ok, I can see how that might work… trying to bridge datalog and clojure syntaxes. On the other hand prolog syntax exists already — and could trivially express that too. Just bind a library of predicates for maps (prolog dicts), and lists. he says waving his hands furiously over all the details

😆 I guess I just miss working in Prolog!

All I need is a syntax for binding variables to parts of structures, but everything else is Datalog

It’s on the backburner for the moment, but I’ve also been trying to learn how Prolog engines are implemented, wondering if I can extend my Datalog implementation to take on more Prolog capabilities

yeah agreed… At some point though I wonder if you’ll ask yourself whether you really want to maintain two syntaxes

I don’t really maintain Pabu. It was something I knocked up quickly overnight 🙂

hehe well you have at least one user now 🙂

I’ve updated it a couple of times, and I’m happy to do so. It’s pretty easy

yeah it’s very simple; but I like it — feels like prolog 🙂 However as I said I’m just noodling about, so if you were to drop it I could switch to the naga side… I probably should as that’s where most of the action is.

The source code for Naga is done with an unusual parser: Parsatron. It’s a parser combinator.

If I write a new parser I’ll probably use Instaparse

yeah I’ve seen

But Parsatron was fun to use

I’ve used Instaparse too and would recommend

Yes, it makes more sense

But Nate Young is a friend, and I liked his presentation at Strangeloop (2010, I think)

Ah, it was 2011

As a user my only gripe with pabu is that when the parse fails you don’t get an error… so it can be hard to distinguish syntax errors from semantic / data ones.

Yes, it was really hard to figure that part out

So Instaparse would probably make that better

https://www.infoq.com/presentations/Parser-Combinators/

IIRC Instaparse has a combinator layer too — though the EBNF stuff is magic. I’ve essentially pasted in EBNF from RFCs and only had to tweak a few things, and it mostly just works! It’s magical.

Appropriate responses for poorly structured syntax is really tough. Asami struggles with that with queries

More accurately… I struggle with doing that

If your :find clause includes things that aren’t in the :where clause then it doesn’t fail. Instead, you get weird projections.

Which I can fix, but I don’t want to hit performance too significantly

👌 Awesome! Be sure to let me know when you have something going.

I still feel like what the prolog folk did 20, 30 maybe even 40 years ago, is beyond what many folk in databases etc consider to be the state of the art.

Well, Prolog isn’t Database oriented. I’d like to bridge that gap, if I can

but I need to understand it better

I think it’s closer than you might think

but not quite sure what you mean by not database oriented 🙂

From what I’ve seen… yes

But I still need to see more 🙂

It has extra-logical features… e.g. cut.

That’s process flow control. It would make for something different than Naga’s queue processing

(cut) … which is super useful, but can make reasoning about programs harder. Essentially there are two ways to read/reason about prolog programs. 1. purely declaratively. 2. mechanically. If you use cut, you blow away the declarative reasoning mode; and are forced to reason mechanically.

but you can use it to efficiently implement NAF for example.

Incidentally 20 years ago when I did a small amount of prolog, one of the fastest implementations was sicstus. Some colleagues considered its performance pretty legendary, though we could never justify the license fee. There are quite a few papers about it. Just seen this one which looks like it might be an interesting read: https://arxiv.org/pdf/1011.5640.pdf

Thank you for this!

I have this book… https://www.researchgate.net/publication/220986765_Warren's_Abstract_Machine_A_Tutorial_Reconstruction

You’re welcome 🙇 Yeah I assumed that was the book you had… I downloaded it too once — though I’ve only ever skimmed it 🙂

Not the WAM but also interesting: https://pllab.github.io/cs162-spring17/handouts/handout6-miniprolog-smallstep.pdf

Oo looks good thanks for sharing