This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-01
Channels
- # atom-editor (11)
- # babashka (25)
- # beginners (142)
- # boot (9)
- # calva (3)
- # cider (19)
- # clara (15)
- # clj-kondo (6)
- # cljs-dev (20)
- # clojars (11)
- # clojure (164)
- # clojure-dev (9)
- # clojure-europe (6)
- # clojure-italy (17)
- # clojure-nl (3)
- # clojure-spec (19)
- # clojure-sweden (10)
- # clojure-uk (23)
- # clojurescript (34)
- # code-reviews (31)
- # conjure (20)
- # cursive (14)
- # datomic (54)
- # emacs (1)
- # fulcro (51)
- # graalvm (24)
- # graphql (6)
- # helix (3)
- # jobs (3)
- # kaocha (1)
- # malli (2)
- # meander (15)
- # off-topic (81)
- # pathom (2)
- # re-frame (43)
- # reagent (26)
- # reitit (1)
- # releases (1)
- # sci (12)
- # shadow-cljs (29)
- # sql (22)
- # timbre (3)
- # tools-deps (15)
Is there an idiomatic way to do hierarchical rules in clara? I have a set of rules that all calculate the same property from a fact but I would like the calculation only to be made by the most specific of the rules that match. I have tried inserting a guard fact when a rule (e.g. [:not [:guard (= (:active this) true] and (insert! {:type guard :active true}
) matches and using salience to control firing order, but this results in an endless loop for reasons I cannot figure out.
As an example I don't understand why the code below goes into an endless loop.
(defrule test-rule
"test guard"
[:not [:guard (= (:active this) true)]]
=>
(do
(println "Inserting guard!")
(insert! {:type :guard :active true})))
(-> (mk-session [test-rule]
:fact-type-fn :type)
(fire-rules))
@mac https://gist.github.com/mrrodriguez/6a6f8373b25d69826b3efe154c928fac this actually has a somewhat similar model as well. For a slightly different goal but notice the guarding not conditions
Then it can activate again and re insert. And again it invalidates itself. So it’s logical looping
@mikerod OK, so the guard gets removed because the LHS match that caused it to be inserted no longer matches?