Fork me on GitHub
#clara
<
2018-05-17
>
dominicm12:05:48

I'm trying to figure out Clara with tuples, partially as I've been brainwashed by Datomic, and partially because I think I like the independence. Precept looks like it's covered a lot of the work for that, any reason I couldn't use it as a general purpose library?

dominicm12:05:41

It's more than possible I should convert the tuples into maps or something, but I'm entirely uncertain.

mikerod12:05:51

@dominicm @alex-dixon is the Precept guru. Clara lets you configure the sort of facts it can work with if you want to do something like tuples. Some of this is explained in http://www.clara-rules.org/docs/fact_type_customization/

mikerod12:05:13

If precept is using tuples already, could look there for example too.

dominicm12:05:45

I did the type customisation for a tuple, it's working out okay, however my rules are full of a lot of destructuring sugar:

(defrule app-asg-min-size
  [:box/type [[e a v]] (= v :server) (= ?app e)]
  [?tup <- :min-size [[e a v]] (= e ?app)]
  =>
  (let [[e a v] ?tup]
    (insert!
      [(str e "-asg") :min-size v])))

dominicm12:05:45

precept does seem to have something to allow queries like this one:

(rule todo-is-visible
  [[_ :visibility-filter :active]]
  [[?e :todo/done false]]
  =>
  (println "The todo with this entity id is visible: " ?e)

dominicm12:05:02

I should probably just try it and see what happens 😛

dominicm13:05:10

It doesn't seem that precept supports newer clara versions, a shame.

mikerod13:05:31

@dominicm I am not aware of anything in a newer clara that broke Precept. That’d be a bit of a surprise to me. Alex has generally been pretty active in the Clara changes etc. hmm.

mikerod13:05:50

As far as the syntactic overhear you mentioned. I think you may be right there. Precept May have defined its own syntax later with something like a macro and then just generated Clara rule forms from it. Not sure. I’d have to check there as well.

mikerod13:05:23

Are you wanting to have it look more like a datalog sort of query I guess?

dominicm13:05:12

@mikerod I can report the bug to Precept, if they will be interested. It would certainly suit my data format better if I did that. I don't think I'm really utilising the "rule type" concept very much. I'm trying to figure out if I can coerce my facts into maps that would be more like what Clara expects, but I'm not sure the type would be more useful there either.

wparker10:05:04

CompilerException java.lang.IllegalArgumentException: Can't define method not in interfaces: insert_facts_BANG_, compiling:(precept/listeners.cljc:14:1) 
I believe the protocol method signature there changes in 0.18.0 so that’s probably it without looking at the code at the moment. It should be an easy uplift though since the new info passed was a superset of the previous (i.e. arguments were added not removed). I’ll comment on the Precept issue later. @dominicm

dominicm10:05:14

yeah, didn't seem like it would be terrible to fix, but I have no context 🙂

mikerod13:05:33

That’s strange. I wonder if Alex will give some feedback on that one soon. I guess to mess with precept for now just use the version it has declared.

mikerod13:05:52

I’ll check that out In a few. Not at laptop at the moment.

mikerod13:05:05

Yeah it is convenient to model data the same as Clara built in. But not necessary of course. Also making a simpler DSL to interact wouldn’t be too hard potentially.

mikerod13:05:44

For tuples. You could make a record type for them that just had an e, a, v fields. Then you’d get more concise Clara syntax at least

alex-dixon14:05:38

@dominicm Hey. I haven’t tried upgrading to 18 yet but there were some breaking changes in 17 that were addressed in this branch https://github.com/CoNarrative/precept/pull/113

alex-dixon14:05:30

@dominicm Is there something in particular in 0.18.0 that you’re interested in having? I’ve been out of the loop

alex-dixon14:05:44

@mikerod I’ve been thinking about the roles/responsibilities of libraries like Precept vs. the Clara core. I’d like the devtools I’ve been working on to be compatible with Clara, but I’m somewhat uncomfortable with thinking of that being part of the core, so I was wondering about the group’s thoughts on revitalizing something like clara.tools to house things like that

mikerod14:05:45

@alex-dixon to me it made sense to have it be a separate library like the clara.tools concept

alex-dixon14:05:03

Now that dominic brings it up, I’m also curious whether Clara would be interested in a Datalog syntax implementation. And yes…I might have asked this a year ago but there’s reasons I didn’t. Namely I didn’t know Clojure at the time, hadn’t really contributed at all to open source, and like now I’m sort of intimidated by Clara’s codebase and not that confident in my ability to work efficiently in it

dominicm14:05:05

@alex-dixon no idea, I just picked latest and started there.

dominicm14:05:35

Datomic syntax for clara in an isolated library would be nice, from a total beginner's pov.

mikerod14:05:11

@alex-dixon It doesn’t have to be in that same repo though really unless you had particular reasoning for that. I haven’t had a chance to look at the devtools stuff that was discussed here the other day. It sounded interesting though

mikerod14:05:02

> Datomic syntax for clara in an isolated library would be nice, from a total beginner’s pov. I agree that that sounds cool

mikerod14:05:33

Probably would be applicable to people in the clj-ecosystem looking into Clara too if that was the sort of data models they were already using. Interesting if Precept already has that layer implemented

alex-dixon14:05:45

The devtools were conceived in isolation, so before I’d work on porting some of it to Clara I’d really want to know what would be useful for people. As it stands, you can view the history of a rule, history of a fact, “event log” (all inserts and retractions in order), see explanations for all of those (the rule conditions that were defined, the facts they matched on, the bindings of the variables, what was inserted or retracted), whether something was inserted or removed unconditionally, logically, or the result of schema enforcement, if it was schema enforcement which existing fact triggered the schema enforcement and the relevant schema rule, added and removed facts for a particular rule firing (i.e. diff), and the total set of facts that exist in the session at the end of any rule firing

alex-dixon14:05:46

It’s implemented as a client and server…the client for visualization, the server for receiving messages from the inspected session/app over socket

mikerod14:05:15

@alex-dixon sounds really useful. You should make it public in a github repo or something for people to try out 🙂

alex-dixon14:05:33

Yeah haha…I definitely will, I’ve been dragging my feet because I’m not completely happy with it

mikerod15:05:29

call it alpha 😛

dominicm16:05:00

I have been using the fact graph for fact history, it's been a pretty cool demo. I wired it up to rhizome pretty easily, and was able to see that X created asg Y, and asg Y has property Z because of Rule A

zylox16:05:06

im certainly interested as well. i agree with @mikerod, just mark it alpha. works for spec right 😛

dominicm16:05:32

the alpha stuff works very well, as long as your namespaces are .alpha too

alex-dixon16:05:31

I’ll try to publish it this weekend, maybe just mentioning it here will make that easier 🙂

alex-dixon16:05:42

Thanks for the encouragement and feedback