Fork me on GitHub
#asami
<
2021-03-05
>
rickmoynihan00:03:42

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

rickmoynihan00:03:36

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

quoll00:03:46

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

👍 1
quoll00:03:08

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

rickmoynihan00:03:11

oh sorry I missed that bit of the message

quoll00:03:33

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

quoll00:03:01

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

quoll00:03:16

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

rickmoynihan00:03:20

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

rickmoynihan00:03:40

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

rickmoynihan09:03:17

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

rickmoynihan09:03:36

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).
Which would I think allow for usage something like this:
ta:error(eq-diff2) :- owl:AllDifferent(XXX),
                      owl:members(XXX,List),
                      ta:compare(List,XXX,ZZZ),
                      owl:sameAs(XXX,ZZZ).
:thinking_face: I can obviously represent ta:compare/3 as a list; but here I think I’m probably better just avoiding the issue and inlining the definition.

quoll16:03:36

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

rickmoynihan16:03:01

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.

quoll16:03:27

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 _]

quoll16:03:10

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

rickmoynihan16:03:06

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

quoll16:03:14

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

quoll16:03:28

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

quoll16:03:59

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}}
But this is a bit vague for now

quoll16:03:06

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

quoll16:03:19

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

quoll16:03:17

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

rickmoynihan16:03:27

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

rickmoynihan16:03:09

😆 I guess I just miss working in Prolog!

quoll16:03:37

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

quoll17:03:20

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

quoll17:03:40

I have a book on the WAM (Warren Abstract Machine). I’ve started trying to implement a WAM in Clojure

rickmoynihan17:03:04

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

rickmoynihan17:03:45

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.

quoll17:03:23

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

quoll17:03:28

but I need to understand it better

rickmoynihan17:03:22

I think it’s closer than you might think

rickmoynihan17:03:37

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

quoll17:03:42

From what I’ve seen… yes

quoll17:03:50

But I still need to see more 🙂

rickmoynihan17:03:04

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

quoll17:03:46

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

rickmoynihan17:03:22

(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.

rickmoynihan17:03:23

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

rickmoynihan17:03:23

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

quoll18:03:10

Thank you for this!

rickmoynihan18:03:44

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

rickmoynihan21:03:43

Oo looks good thanks for sharing

rickmoynihan17:03:10

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

quoll17:03:59

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

rickmoynihan17:03:24

hehe well you have at least one user now 🙂

quoll17:03:38

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

rickmoynihan17:03:21

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.

quoll17:03:07

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

quoll17:03:25

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

rickmoynihan17:03:26

yeah I’ve seen

quoll17:03:38

But Parsatron was fun to use

rickmoynihan17:03:47

I’ve used Instaparse too and would recommend

quoll17:03:05

Yes, it makes more sense

quoll17:03:30

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

quoll17:03:42

Ah, it was 2011

rickmoynihan17:03:01

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.

quoll17:03:22

Yes, it was really hard to figure that part out

rickmoynihan17:03:24

So Instaparse would probably make that better

rickmoynihan17:03:20

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.

💖 1
quoll17:03:41

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

quoll17:03:16

More accurately… I struggle with doing that

1
quoll17:03:22

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

quoll17:03:37

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