This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-06
Channels
- # adventofcode (24)
- # aleph (1)
- # bangalore-clj (2)
- # beginners (196)
- # boot (148)
- # cider (18)
- # clara (83)
- # cljsrn (24)
- # clojure (210)
- # clojure-brasil (3)
- # clojure-china (1)
- # clojure-italy (11)
- # clojure-korea (8)
- # clojure-russia (82)
- # clojure-spec (115)
- # clojure-uk (130)
- # clojurescript (109)
- # core-async (7)
- # cryogen (1)
- # cursive (22)
- # datascript (11)
- # datomic (6)
- # devcards (2)
- # emacs (1)
- # garden (1)
- # hoplon (2)
- # incanter (1)
- # klipse (4)
- # luminus (4)
- # off-topic (89)
- # om (53)
- # onyx (78)
- # parinfer (9)
- # proton (3)
- # protorepl (20)
- # re-frame (107)
- # reagent (52)
- # rum (30)
- # spacemacs (1)
- # testing (3)
- # untangled (31)
- # vim (43)
- # yada (9)
i’m talking a bit of gibberish i suppose, but will was talking about synthesizing the “last 10%” of your program
i wonder if generating the “last rule” in a smallish rulebase would be an interesting place to try that out
For me, the writing the rules is the "easy part" but knowing if my rules cover what I think they do is the hard part
(I'm saying this as someone who is completely entranced by Barliman. I love that stuff, and I cloned the repo for the flight home)
Or our actual situation: here's a ns of rules, is it possible more than one can fire?
Again might be unique to the way I use clara-rules, but I have a hierarchy that looks like:
And I want just one final action rule to fire (this doesn't actually do a side effect. Something else uses the output of the rule engine to take an action)
jonsmock I agree that more tooling would be a big win and is one of the harder parts.
thanks. it’s a bit basic I’m sure given how much you are already entrenched in the details of working with rules.
@jonsmock Maybe a SAT solver can be used in some sort of tooling around rule analysis 🙂
The inspect session output I believe can answer that, but it would require carrying around some state between tests
I think I've played around with property tests and rules, but I don't know if we have any at the moment
I'm curious if you have the same organization to your rules. We basically have 3 tiers ... oh I guess I said this above
the basic fact rules are basically digging out important stuff from giant maps from other systems
we built a library that builds facts, and their variants (intermediate facts) using a bit of macro sugar
(deffact FooFact
“Blah blah"
(alias foo-fact
(field some_id :spec string? :doc “blah blah”)
(variant InterestingFooFact
(field additional_field :spec number? :doc “…”)))
we also introduced a trace_id on all fact types, which is carried around, so you can track the lineage of a fact a bit easier
So I'm thinking like (deffact TotalCharges ...) and having other facts declaratively say that they are less than TotalCharges
and, we have a :contributing_factors field on many (not all) facts, which captures interesting “why” information
@jonsmock we also have (optional-field …), and a way of specifying an explanation for each fact, so if you call (explain the-fact), it’ll give you the view you’re looking for
to date we haven’t actually used explain, which is just a function of the history of this project
“why did we make an InterestingRecommendation?” => “Patient is over 50 and has a recent encounter (< 45 days) where X happened…"
We built a graph you can traverse by clicking from nodes to rules and such, but textual explanation seems to be more fundamentally valuable
Ryan’s clara.tools project is on the right-ish track, but the sheer volume of information for a graph of any decent size can quickly turn into wading in a swamp of facts which aren’t all that interesting