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?
It's more than possible I should convert the tuples into maps or something, but I'm entirely uncertain.
@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/
If precept is using tuples already, could look there for example too.
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])))
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)
I should probably just try it and see what happens š
It doesn't seem that precept supports newer clara versions, a shame.
@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.
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.
Are you wanting to have it look more like a datalog sort of query I guess?
@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.
@mikerod in case you're interested https://github.com/CoNarrative/precept/issues/115
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. @dominicmyeah, didn't seem like it would be terrible to fix, but I have no context š
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.
Iāll check that out In a few. Not at laptop at the moment.
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.
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
@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
@dominicm Is there something in particular in 0.18.0 that youāre interested in having? Iāve been out of the loop
@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
@alex-dixon to me it made sense to have it be a separate library like the clara.tools concept
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
@alex-dixon no idea, I just picked latest and started there.
Datomic syntax for clara in an isolated library would be nice, from a total beginner's pov.
@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
> Datomic syntax for clara in an isolated library would be nice, from a total beginnerās pov. I agree that that sounds cool
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
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
Itās implemented as a client and serverā¦the client for visualization, the server for receiving messages from the inspected session/app over socket
@alex-dixon sounds really useful. You should make it public in a github repo or something for people to try out š
Yeah hahaā¦I definitely will, Iāve been dragging my feet because Iām not completely happy with it
call it alpha š
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
im certainly interested as well. i agree with @mikerod, just mark it alpha. works for spec right š
the alpha stuff works very well, as long as your namespaces are .alpha too
Iāll try to publish it this weekend, maybe just mentioning it here will make that easier š
Thanks for the encouragement and feedback