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

šŸŽŠ 4
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

šŸ‘ 4
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

šŸ‘ 8
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

šŸ‘ 4
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

šŸ‘ 4
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

4
šŸ‘ 4