This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-11
Channels
- # announcements (6)
- # babashka (61)
- # beginners (85)
- # calva (21)
- # cider (6)
- # clara (9)
- # clj-http (1)
- # clj-kondo (35)
- # cljfx (6)
- # clojure (91)
- # clojure-australia (11)
- # clojure-europe (23)
- # clojure-italy (7)
- # clojure-losangeles (2)
- # clojure-nl (27)
- # clojure-uk (107)
- # clojurescript (4)
- # community-development (1)
- # cursive (69)
- # emacs (12)
- # fulcro (29)
- # graalvm (25)
- # honeysql (10)
- # hugsql (3)
- # integrant (13)
- # jobs (4)
- # kaocha (3)
- # keechma (1)
- # lambdaisland (3)
- # leiningen (2)
- # meander (17)
- # mount (3)
- # observability (1)
- # off-topic (86)
- # pathom (3)
- # polylith (2)
- # practicalli (14)
- # reitit (14)
- # shadow-cljs (61)
- # startup-in-a-month (1)
- # tools-deps (9)
- # vim (54)
- # xtdb (16)
I've recently been thinking of playing with rules engines (perhaps I need a hobby?) I recently watched and enjoyed (@sekao is a funny character. ) this presentation on O'Doyle - https://youtu.be/XONRaJJAhpA The talk references Clara a lot. I wondered though does O'Dolyle have the ability to explain why a rule was executed... I'm starting to think about using a rules engine, and the idea of being able to trace why a rule fired seems important. Also did O'Dolye not have retraction? He mentioned you can "replace" a fact.
@bherrmann I still need to watch that talk on O’Doyle. It did sound to me like what it wasn’t planned to have is a truth maintenance system. This is a key part of Clara’s feature sets/priority. It allows rules to be written in a way that is less coupled to order of evaluation and instead a more “declarative logic system”. Also, there is retraction, but typically external to the rules retraction tends to be the more stable given the truth maintenance system mentioned.
Clara has a few built in facilities to give back various granularity detailed traces of what happened within the rules engine - which can include inserts and retract etc. For a higher-level view though, it often is enough to just write rules in a way that track their “supporting facts” directly
(defrule do-thing-with-support
[?a <- A]
[?b <- B]
=>
(r/insert! (map->C {:value :something
:support [?a ?b]})))
(defrule do-other-with-support
[?c <- C]
[?d <- D]
=>
(r/insert! (map->E {:value :other
:support [?c ?d]})))
;;; Later
(defn get-supporting-facts [{:keys [support] :as fact}]
(into support
(mapcat get-supporting-facts)
support))
and you can also just build helpers for these sorts of things to not be so repetitive in rules
With truth maintenance, a nice part is if facts becomes invalidated because newer insertions cause formerly fired rules to become false, then they are automatically retracted and the rule network re-establishes consistency across the rules - which would fix these supporting facts as well.