Clojurians Log v2

Is Clara’s fact destructuring as described here: http://www.clara-rules.org/docs/expressions/ the same as Clojure’s destructuring?

@cfleming the part of the syntax shown there uses Clojure destructuring. It basically ends up being a clojure function arglist that takes a single object.

But yes. It just “flows through” to standard destructuring.

Ok, great, thanks.

No problem.

@mikerod One more question while I have you - in the doc, is FACT_CONSTRAINT always a Fact Expression as defined in the doc, or is it any condition?

(I’m working on specs for the Clara macros right now)

taking a look

I don’t see a FACT_CONSTRAINT referenced in http://www.clara-rules.org/docs/expressions/ ?

nevermind see it

It’s in Boolean Expressions and also Accumulators

Ok, it is a fact expression as referred to above

Great, thanks.

Hopefully I’ll have something basic working soon, I’ll push it for comments - there are still a bunch of TODOs in there.

There may be times when it is odd to do something like bind a fact to a variable, but I think the syntax typically allows these cases - even if they don’t end up being useful.

That is cool. Sounds interesting

I’ll try to give a look at it too once you have it out there.

Great, thanks - this is re: https://github.com/cerner/clara-rules/issues/367

I’m still catching up on the GitHub conversation from earlier

Cool, no rush.

I’ve pushed https://github.com/cursive-ide/clara-specs

It contains a first cut at specs to match the macros in the Clara DSL - they match all the examples from the documentation correctly as far as I can tell.

There are still some TODOs in there which weren’t clear to me from the doc, mostly stubbed out with any?

My next task is to try it on the clara-examples repo and make sure it works for the examples there too.

@alex-dixon @mikerod ^^ FYI

@cfleming nice. This is looking pretty good. I have looked over it fairly quick. I see a few things to tweak but mostly it is looking pretty close to what I’d think is right

Great, thanks - feel free to file an issue or just let me know what to change and I’ll update it.

I’ll have to figure out how the symbol resolution should work for unification variables too.

(in Cursive, that is, not required for the specs).

Tomorrow I can give some better notes. A GitHub issue there perhaps to hold them.

Easier things: the LHS can have 0 conditions.

Great, thanks. I’m going to be in and out over the holiday period but I’ll try to get it fixed up when I get a moment.

The RHS can have multiple forms now I believe.

Ok, so the RHS is like a body?

Fact type really can be like anything. So that’s a harder one I think.

Yeah RHS is just like an implicit do

Block

Ok.

But I guess it should always have at least one form?

Yeah I believe the RHS needs at least one form.

If it didn’t it wouldn’t be a useful rule at least. Hah

Hehe

Thanks for trying this out!

Also, in the defquery doc it shows CONDITION repeated inside []

I’m not sure what that’s supposed to look like, the examples don’t have repeated vectors inside that.

I’ll have to check that one out.

Ok, thanks.

Ok, I’ve got to step out now, thanks for the feedback! It’s already Friday afternoon here so if you can file an issue or something with any further feedback I’ll get to it when I can.

Sounds good. Thursday night here. Hah. I’ll see what else I can point on there likely tomorrow morning.

Perfect, thanks Mike!

@mikerod I experimented after your notes. Have better understanding now. Your note helped 🙂

There is docs about props? http://www.clara-rules.org/docs/rules/ :salience is the unique "relevant" value inside this map?

@souenzzo I’m not sure if there are docs about all props

It is a map of keyword to anything. :salience is one supported one. The only other I can think of is :no-loop

and usually you shouldn’t need to worry about :no-loop

I'm annotating some data to use on inspect. outside a name conflict, should not be a problem, right?

You want to put additional information in the props map for your own purposes you mean?

Yep

I think that should be ok. You probably want to do something like use namespaced keywords though as keys

@mikerod Could no loop could be used as a modify? Like if I wanted to increment each match at most once per fire rules?

@alex-dixon like:

(r/defrule demo
  {:no-loop true}
  [?a <- A]
  =>
  (r/insert! (update ?a :some-val inc)))

?

and perhaps with a RHS (r/retract! ?a) before - actually not sure on this part - it is a secondary part of the question

With retract yeah. To simulate mutation

It may be feasible, something you’d want to be careful for proliferating everywhere

with r/retract! I actually dont’ know

I can’t remember if :no-loop will stop a truth maintenance retraction sort of loop - perhaps you’ve tried?

I’ve mentioned on here before as well, if you don’t have a big concern with an always growing set of facts in working memory, you don’t need to retract. You can just “modify” and only base downstream logic on the “latest”

however, for something long running or with many of these changes, memory use would get too high

@mikerod This is the first I’ve heard of no loop! I’m excited by it. Here’s an issue you raised a few years ago, looks like it led to truth maintenance being brought under the “no loop” umbrella as well: https://github.com/cerner/clara-rules/issues/99

@alex-dixon oh nice. The memory has returned to me now (after reading that issue and comments again) hah

It’d be interesting to see how doing something like you said would go then

if you retract the fact and insert the updated version of it

then all other rules that were based (or transitively based) only that removed fact would be retracted. However, the new updated version of the fact would then be available to rebuild those downstream results

That ma work out alright.

@alex-dixon but be aware there are some edge cases to RHS retracts still.

https://github.com/cerner/clara-rules/issues/229 https://github.com/cerner/clara-rules/issues/321 are 2 I can immediately find

I’m trying to understand the difference with that behavior and insert logical vs insert unconditional with an explicit retraction….kind of a head spinner. It seems a lot of the landmines and complexity are tied up with insert logical. Would you agree?

@alex-dixon Hmm. I think sticking to all logical insert is a reduction of complexity

There are just cases when it is difficult to express what you want with only the built-in logical truth maintenance.

Doing things like unconditional insert and RHS retracts are subversions to the truth maintenance system (aka TMS). With that comes difficulty

The reason TMS and logical insertion are so useful is that they allow for a much larger degree of rule order evaluation independence.

I think what Clara may be lacking most is a way to explicitly “update” a fact.

The more I think of it coming up, the more it seems like it’d be a nice first-class thing that ensured that it had well defined semantics with how it interacted with TMS.

However, I have mentioned before, that you can also make an external process that handles “updates” or retractions - leaving the rules part all logical insert + TMS.

However, that is still a manual thing right now. I’ve posted on here a few times what that sort of thing looks like though.