Clojurians Log v2

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?

@tony.kay sounds like a bad idea 😛

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

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

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

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

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

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

although it doesn’t provide an ideal solution

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.

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

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

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).

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

@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?

(e.g. they are using unconditional inserts)

oh, I guess you mentioned that…unconditional

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

I lost track while reading the article 😜

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

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

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

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

(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)))

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

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

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

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