This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (3)
- # aleph (24)
- # architecture (8)
- # beginners (53)
- # boot (34)
- # cider (7)
- # clara (68)
- # cljs-dev (6)
- # cljsrn (3)
- # clojars (10)
- # clojure (71)
- # clojure-germany (2)
- # clojure-italy (10)
- # clojure-nl (25)
- # clojure-serbia (4)
- # clojure-spec (13)
- # clojure-uk (48)
- # clojurescript (31)
- # core-async (62)
- # cursive (13)
- # datomic (4)
- # duct (76)
- # editors (4)
- # fulcro (2)
- # immutant (1)
- # instaparse (1)
- # jobs (1)
- # lein-figwheel (1)
- # mount (1)
- # off-topic (12)
- # onyx (8)
- # re-frame (10)
- # reagent (84)
- # reitit (2)
- # ring (2)
- # shadow-cljs (159)
- # spacemacs (2)
- # specter (17)
- # sql (14)
- # tools-deps (10)
- # yada (15)
I'm guessing the second [Derived 1] is retracted after insertion, though that isn't what I want, in fact in my POC rule set I'm doing an
insert-unconditional! because the fact must survive, subsequent retraction, but I still only one exactly one instance to be inserted, i.e. one-time initialization.
I’m not a huge fan of those, because they cause rules to become more order dependent’
In my case, I need to add a fact to the system, once to "initialize" the absense of a missing fact. The fact needs to survive truth maintenace because I am going to retract the basis for creating it, but not the need for using it later on
Anyway, I'm clearly not yet in the mindset of thinking the way clara wants me to think. I'd expect a rule like
[:not [Foo]] => (insert-unconditional! (->Foo)) to fire exactly once, but clearly my assumptions are wrong.
Wouldn’t call that a bad assumption but that rule effectively means when not foo foo and when foo not foo
if you use
insert! the behavior is a contradiction, with
insert-unconditional! it is different
There is also a property you can add to rules, I don’t typically like to add it though, but it is
it may be able to stop a logical loop from a contradicting rule like you have here with
insert!, but I’d have to mess with that again
Oops, yes, my code snippet iwth the infinite loop isn't interesting. When I use
insert-unconditional it's still firing more than once
insert-unconditional! will result in a firing for each of your
Fact objects, so 3 is rigth
The rules do not treat the working memory as something like a set. It allows “duplicates”. There are useful cases for that - scratch this
I think it may be an “edge case” on
insert-unconditional! behavior in the engine. I’d probably call it incorrect how the engine is behaving
I'm confused because on the one hand, the RHS of one rule can impact the firing of another rule. But in this case it's like both checks for a [Derived 1] correpesponding to a [Fact 1] took place at the same time, neither aware of the others effect, and unsure how to bridge that.
Like I said, I’m not a fan of
insert-unconditional! and try to not use it much because I think it makes things have order dependence and always trickier to reason about as far as “global logical consistency” across the rules
I think all 3 matches are staged independent of one another and all perform
insert-unconditional! at the “same time”
since they are unconditional, the truth maintenance isn’t used to remove the logical inconsistencies
Okay, well, I'll remedy my immediate problem by doing what is fundamentally an initialization step outside of the rule firing and add my initialization outside of the firings (i.e. not in an RHS via
insert!, but via
Wondering if behavior is different if derived is inserted without ?x...maybe y instead
I'm definitely still struggling with these little things, though logic principles of
[not x] => [x] is a good way ot look at it in my thinking for the future.
@dave.tenny oftentimes, and I’ve said this quite a bit here before, I try to separate the desire of “cardinality” into a different rule from the rule that has the logic to derive the fact in question
This particular one is very unfortunate though, if it worked it was much nicer and more foolproof when done via a rule firing.
So instead of worrying about a rule producing too many of something, I let it produce them, and reconcile them with a separate rule and an accumulator
@mikerod what’s the upside to the batched unconditional insertions implementation? Is it possible to still attain those benefits without eliciting behavior like this?
this case is a bit different in a way, but if your real concern is only that you don’t want 2
Derived :y 1 facts, it applies
However, in the unconditional case, it now concerns me a bit since the truth maintenance won’t “fix it” when different unconditional inserts cause the other to become untrue
however, that is a really gray area to me. if it did behave right, how would it choose which unconditional insert wins, when they contradict each other? In the general case.
On an unrelated topic, can you recommend tools for pretty-printing/organizing
get-trace output to assist with reading it? I made my first attempt at decoding that stuff to debug, but as a raw clojure nested structure it's rough going for a first try.
Joking.. but he has said he had a better visualization thing. The trace results will be pretty verbose and clj data structures. Inspect was supposed to have a few friendlier printers I think. I haven’t used inspect much.
Of course what I really want is a simple movie-mode rule tracing with verbose-mode description of clause evaluation impact on rule consideration/rejection. Heh, or is that
[:test (do (prn "here I am") true)] in the LHS?
@dave.tenny yeah, you can print stuff. I think the tracing output can be used alright, but it’s mostly just composing functions on it to show it however is useful.
Haven't seen any "tips and tricks" documentation for the sorts of things a newbie could use for debugging
Yeah, I think this may be something that is lacking (and would be really nice to have).
@mikerod It’s not better according to me. And yeah…I’m working on it again this weekend 🙂
Might open an issue in Clara about adding Datalog syntax as a separate clara library. For something like the precept devtools concept I’m not sure how that would work….would need to think about it or have some direction from others. A lot of the way I thought about it was Precept-specific. I think the main difference is that there’s framework to manage session transitions, so there’s code that’s aware of when rules are firing and when they’re done firing that allows them to be identified and numbered