Fork me on GitHub
#clara
<
2017-12-22
>
cfleming02:12:50

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

mikerod02:12:35

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

mikerod02:12:00

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

cfleming02:12:04

Ok, great, thanks.

mikerod02:12:40

No problem.

cfleming02:12:19

@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?

cfleming02:12:05

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

mikerod02:12:25

taking a look

mikerod02:12:40

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

mikerod02:12:51

nevermind see it

cfleming02:12:12

It’s in Boolean Expressions and also Accumulators

mikerod02:12:43

Ok, it is a fact expression as referred to above

cfleming02:12:00

Great, thanks.

cfleming02:12:29

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

mikerod02:12:52

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.

mikerod02:12:58

That is cool. Sounds interesting

mikerod02:12:15

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

mikerod02:12:23

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

cfleming02:12:37

Cool, no rush.

cfleming03:12:22

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.

cfleming03:12:45

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

cfleming03:12:11

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

cfleming03:12:04

@alex-dixon @mikerod ^^ FYI

mikerod03:12:05

@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

cfleming03:12:53

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

cfleming03:12:11

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

cfleming03:12:23

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

mikerod03:12:57

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

mikerod03:12:20

Easier things: the LHS can have 0 conditions.

cfleming03:12:31

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.

mikerod03:12:32

The RHS can have multiple forms now I believe.

cfleming03:12:46

Ok, so the RHS is like a body?

mikerod03:12:11

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

mikerod03:12:32

Yeah RHS is just like an implicit do

cfleming03:12:16

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

mikerod03:12:39

Yeah I believe the RHS needs at least one form.

mikerod03:12:00

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

mikerod03:12:54

Thanks for trying this out!

cfleming03:12:13

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

mikerod19:12:17

This is just a mistake in the docs. it should be the same as a rule in this part of a query

cfleming02:12:13

Great, thanks Mike

cfleming02:12:08

Looks like these are pretty close to correct then. Thanks for the great doc, a few ambiguities and mistakes like the above aside, it was great and really helpful in making these.

cfleming02:12:30

Once these are done perhaps the doc could be created from them in the future.

mikerod02:12:56

Yeah t is looking good. I agree too that it would be nice to align the docs to it potentially could help ensure they stay correct too.

mikerod02:12:20

So I guess we need to figure out how to go about getting the specs in the repo. I think it’d be good to hear some feedback from at least @ on it too. He is on vacation and traveling a bit I believe (common for many right now in US). That’s probably why he hasn’t said much on the subject yet.

cfleming02:12:11

Ok, no problem. They could be provided as a separate clara-specs artifact, too, if getting them in the main repo were undesirable.

mikerod02:12:30

Yeah a separate artifact is easy enough. I am thinking the main repo may be a good place too though. I just wanted to hear a bit of feedback from others there. It looks like it could be like an optional require sort of thing too so it wouldn’t mean that Clara couldn’t still support older clj for those not using it yet.

cfleming02:12:03

Right, as long as users on <=1.8 don’t require that ns, they won’t have a problem.

mikerod02:12:14

Clara already has an “optional” sort of dependency on Fressian (for a default durability layer impl). So it wouldn’t be the first of that sort.

mikerod02:12:56

We should reference your repo in the github issue on Clara related to this spec’ing too to be sure everyone sees it

mikerod02:12:13

I’m sure people will like to get some cursive support from this too. That seems like it could be really useful

cfleming02:12:53

Yeah, Cerner are big Cursive users so it will help a lot of people there (and elsewhere) I think.

cfleming02:12:32

I’ll probably have some questions about how the symbol resolution in conditions works too, once I get that far.

cfleming02:12:45

That looks a little tricky.

mikerod02:12:20

Yeah it sounds like there is a good audience for it. It is a good way to get the cursive functionality some good exposure and perhaps testing too.

mikerod02:12:10

Yeah. Let me know if you have any questions about Clara concerning that. I can try to assist with what I can in terms of Clara semantics or whatever.

cfleming02:12:13

Great, thanks. I’m unlikely to get much done until the beginning of Jan now, but I might tinker a bit over the holidays.

mikerod02:12:13

Sounds good

cfleming02:12:04

Thanks for all the help, and happy holidays!

mikerod02:12:15

Thanks. You too!

cfleming03:12:42

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

mikerod03:12:56

I’ll have to check that one out.

cfleming03:12:02

Ok, thanks.

cfleming03:12:52

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.

mikerod03:12:54

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

cfleming03:12:05

Perfect, thanks Mike!

amarjeet12:12:05

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

souenzzo13:12:58

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

mikerod14:12:56

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

mikerod14:12:17

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

mikerod14:12:00

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

souenzzo14:12:53

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

mikerod14:12:52

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

mikerod14:12:12

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

alex-dixon18:12:25

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

mikerod18:12:56

@alex-dixon like:

mikerod18:12:01

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

mikerod18:12:36

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

alex-dixon18:12:48

With retract yeah. To simulate mutation

mikerod18:12:00

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

mikerod18:12:17

with r/retract! I actually dont’ know

mikerod18:12:36

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

mikerod18:12:54

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”

mikerod18:12:38

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

alex-dixon22:12:02

@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

mikerod23:12:42

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

mikerod23:12:36

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

mikerod23:12:43

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

mikerod23:12:26

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

mikerod23:12:31

That ma work out alright.

mikerod23:12:38

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

alex-dixon23:12:42

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?

mikerod23:12:37

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

mikerod23:12:07

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

mikerod23:12:44

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

mikerod23:12:27

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

mikerod23:12:51

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

mikerod23:12:25

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.

mikerod23:12:25

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.

mikerod23:12:48

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.