Fork me on GitHub
#clara
<
2018-06-25
>
tony.kay17:06:16

Hi, is it ok to use *current-session*? it isn’t documented, but it would be handy to run queries during rule execution…or is that just a bad idea?

mikerod18:06:13

@tony.kay sounds like a bad idea 😛

mikerod18:06:26

Are you wanting to use it for debugging or for more than that?

tony.kay18:06:14

So, we have facts that are stored in a datomic-fashion…so “insert” needs to know if the fact (as an E/A pair) is already present so we can retract the old value before inserting the new one

mikerod18:06:30

The thing is (a) it isn’t documented/impl detail, so would be subject to breaking changes (b) but even more worrisome is that there isn’t any strong guarantees about rules firing order or if a rule will be fired/retracted/re-fired etc So arbitrarily looking into the *current-session* could cause problems

tony.kay18:06:33

so, we need to know what is in the current session

tony.kay18:06:01

yeah, I understand that, but rule firing order doesn’t matter in that case…I need to know if a fact is in there right as that rule fires

mikerod18:06:16

I think that http://www.metasimple.org/2017/12/23/clara-updating-facts.html relates to this concept of safely “updating” facts

mikerod18:06:28

although it doesn’t provide an ideal solution

mikerod18:06:28

You can use things like insert-unconditional! and also :no-loop properties on a defrule to attempt to do things like you are describing. However, I try to avoid those since they become more imperative/order-dependent etc in nature. Also, they can have interactions at odds with the rest of the truth maintenance system.

mikerod18:06:52

In the post linked above, I mention “Approach 1: Append only updates”

mikerod18:06:10

that’s the easiest, but can run up against memory limits depending on how you are using things

mikerod18:06:19

I didn’t explain in that post, but I think the “Approach 1: Append only updates” could be extended to have an external process/fn that cleans up old UpdatingFactSnapshot later (using a query to access them externally).

tony.kay18:06:08

cool, thanks. I’ll read the article. I’m sure I’m missing somehting about the TMS that I’m not clear on 🙂 Hopefully that’ll get me squared up

tony.kay19:06:29

@mikerod so, in the project I’m helping with, they are not using the logic tracking facility…so invalidating a truth does not auto-retract anything. Perhaps this is a problem that should be addressed as well, but does that affect your answer at all?

tony.kay19:06:58

(e.g. they are using unconditional inserts)

tony.kay19:06:22

oh, I guess you mentioned that…unconditional

mikerod19:06:36

If you use unconditional inserts, those rules will rely on order of firing

tony.kay19:06:39

I lost track while reading the article 😜

mikerod19:06:47

since the rules won’t try to “correct” for inconsistencies if a rule fires in the “wrong order”

mikerod19:06:13

but if you are opting out of truth maintenance, then yeah, you can do unconditional things

tony.kay19:06:41

ok, I’ll try to get to the bottom of why they want to opt-out as well

tony.kay19:06:56

I agree it would be nice to reason about things in isolation

mikerod19:06:56

(defrule udpate-it
  [?old-one <- A (= ?e e) (= ?a a)]
  [?new-one <- NewA (= ?e e) (= ?a a)]
  =>
  (retract! ?old-one)
  (insert-unconditional! (map->A ?new-one)))

mikerod19:06:07

I’d worry a bit about pervasive use of unconditional inserts

mikerod19:06:33

it misses out on one fairly large advantage of the rules engine - which is a declarative logical truth maintenance system.

mikerod19:06:58

If unconditional is used, it’d be best to a least to try to isolate it to some fringe “layer” of the logic

tony.kay19:06:44

yeah, these are more derived new facts…but I see your point about invalidating the condition of the rule you’re running