This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-22
Channels
- # beginners (24)
- # boot (80)
- # braid-chat (11)
- # cider (89)
- # clara (11)
- # cljsfiddle (5)
- # cljsjs (9)
- # cljsrn (63)
- # clojure (114)
- # clojure-austin (1)
- # clojure-berlin (5)
- # clojure-brasil (4)
- # clojure-dusseldorf (5)
- # clojure-hamburg (17)
- # clojure-india (1)
- # clojure-new-zealand (3)
- # clojure-poland (1)
- # clojure-russia (91)
- # clojure-taiwan (1)
- # clojure-uk (54)
- # clojurebridge (3)
- # clojurescript (170)
- # core-matrix (1)
- # cursive (14)
- # datomic (8)
- # emacs (13)
- # hoplon (96)
- # immutant (20)
- # jobs (9)
- # jobs-rus (13)
- # kosmos (3)
- # off-topic (8)
- # om (111)
- # onyx (41)
- # parinfer (116)
- # pedestal (2)
- # proton (4)
- # re-frame (46)
- # reagent (7)
- # ring-swagger (24)
- # slack-help (2)
- # testing (1)
- # untangled (8)
is it the same as https://groups.google.com/forum/#!topic/clara-rules/F-8vcsZC2i4 ?
We don't need to retract here. I pushed back against the use of it, but it worked, until we bumped to 0.11.0 of course
This goes against the concept of logical truth maintenance of inserted facts. Retracts will often lead you into bad situations when it comes to truth maintenance. In this particular scenario, the rule shouldn't insert anything because anything it inserts loses its logical support immediately, due to the retract of all the recommendations.
In our use-cases, we avoid retracts pretty much completely. We like to rely on the logical truth maintenance of inserts to do any "retracts" for us. It does involve adding new fact types occasionally, which Clara's default is via :type metadata or the Java class hierarchy (on Java side) or JS hierarchy (on JS side)