This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (37)
- # beginners (74)
- # boot (2)
- # boot-dev (31)
- # cider (88)
- # clara (109)
- # cljs-dev (63)
- # clojure (96)
- # clojure-argentina (1)
- # clojure-czech (1)
- # clojure-dusseldorf (2)
- # clojure-france (2)
- # clojure-germany (3)
- # clojure-greece (2)
- # clojure-italy (5)
- # clojure-norway (1)
- # clojure-spain (1)
- # clojure-spec (25)
- # clojure-uk (46)
- # clojurescript (26)
- # cursive (19)
- # data-science (5)
- # docs (2)
- # duct (18)
- # editors (2)
- # emacs (3)
- # figwheel (2)
- # fulcro (29)
- # graphql (3)
- # hoplon (143)
- # juxt (7)
- # klipse (1)
- # leiningen (5)
- # lumo (1)
- # monads (1)
- # off-topic (23)
- # onyx (49)
- # powderkeg (6)
- # re-frame (4)
- # reagent (8)
- # ring (3)
- # shadow-cljs (24)
- # specter (70)
- # sql (1)
- # unrepl (96)
- # yada (3)
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.
@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 don’t see a
FACT_CONSTRAINT referenced in http://www.clara-rules.org/docs/expressions/ ?
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.
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
My next task is to try it on the clara-examples repo and make sure it works for the examples there too.
@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.
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.
This is just a mistake in the docs. it should be the same as a rule in this part of a query
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.
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.
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 @U0KRSVDHR 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.
Ok, no problem. They could be provided as a separate clara-specs artifact, too, if getting them in the main repo were undesirable.
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.
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.
We should reference your repo in the github issue on Clara related to this spec’ing too to be sure everyone sees it
I’m sure people will like to get some cursive support from this too. That seems like it could be really useful
Yeah, Cerner are big Cursive users so it will help a lot of people there (and elsewhere) I think.
I’ll probably have some questions about how the symbol resolution in conditions works too, once I get that far.
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.
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.
Great, thanks. I’m unlikely to get much done until the beginning of Jan now, but I might tinker a bit over the holidays.
I’m not sure what that’s supposed to look like, the examples don’t have repeated vectors inside that.
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.
@mikerod I experimented after your notes. Have better understanding now. Your note helped 🙂
There is docs about
:salience is the unique "relevant" value inside this map?
It is a map of keyword to anything.
:salience is one supported one. The only other I can think of is
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?
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?
and perhaps with a RHS
(r/retract! ?a) before - actually not sure on this part - it is a secondary part of the question
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
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
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?
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.
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.