@mikerod hm, ok. Idempotency shouldn't be an issue, good hint though. Gonna try that, although I am not 100% clear on how you mean that. In my use case, there would be rules that produce a [Linked a b] fact which would call something like core.async/pipe on a and b, only it returns something that can be called or closed when the respective Linked fact goes away in order to sever the connection again. How would I address that using :not rules?

Clara is awesome btw. ! Played with it a bit more in the meantime

@mrchance an alternative that comes to mind is to hook into Clara’s listeners to try to watch for the particular retraction you are interested in. However, I’d probably say it is best if that isn’t necessary.

I hate to suggest things like insert-unconditional! but I see an approach with that at least…

I’d like to think of something better though

Yeah, I saw the ns in the docs and thought about that

demo:

(defrule makes-chan
  [?a <- A]
  [?b <- B]
  =>
  (let [chan (somehow-make it)]
    ;; Not sure what you do with `chan` here
    (r/insert! (->LogicalThing ?a ?b))
    (r/insert-unconditional! (->OpenedChan chan))))

(defrule closes-chan
  [:not [LogicalThing]]
  [?oc <- OpenedChan (= ?chan chan)]
  =>
  (r/retract! ?oc)
  (close-the ?chan))

I think it just gets sort of dirty when you are managing your own unconditional facts and retracts - typically a pattern to avoid

not sure how prevalent this would be for you though in terms of managing it. also, not positive my solution is really a solution to the issue at all

Ok, I can see what you're getting at, but I agree it looks suboptimal

Clara has a listener protocol you can attach onto

and I believe you can find the relevant retract events there

not sure there have been docs posted up on that

Not many, from what I browsed yet 😉

https://github.com/cerner/clara-rules/blob/master/src/main/clojure/clara/rules/listener.cljc

The ITransientEventListener

even when looking at this though, I think it is perhaps opaque which retraction you’d want to listen to

Hm, maybe. I'll give it a try

I believe (retract-facts! [listener facts]) & (retract-facts-logical! [listener node token facts]) would have the info

retract-facts! I believe is retracts from the RHS and retract-facts-logical! is retracts from truth maintenance

other “retract” things I believe are more internal node-to-node activity

Ah, ok

Thanks! I'll test it

(mk-session rules :listeners [my-listener-impl])

I think there is some big potential here, like a completely reactive description of stateful systems, something that's always awful when it moves past what e.g. component can handle

That's simple enough 😉

yeah, it isn’t actually documented on mk-session, not sure why. I don’t think those ns’s are really called “experimental” around this at this point

the only thing I’m concerned about is if you do not impl all the functions of the protocol

I can’t remember if you have to “pad” those with a no-op in some way

Typical case of documentation not growing as fast as its software

Shouldn't be a problem, it's a one time thing so some boilerplate is no issue

there is the clara.rules.listener/default-listener though

you could just delegate everything else through that

but it’s just a no-op

yeah, idk. I’ve done stuff with this before too. I just can’t remember

Ok, then actually delegating is probably more work ;)

hah yes

I could have swore there was a smoother way

I think this one is good enough, if it works

> I think there is some big potential here, like a completely reactive description of stateful systems, something that’s always awful when it moves past what e.g. component can handle That is cool though

Yeah

would be interesting to hear what success you have with that

Sure, I'll let you know

btw, looks like precept uses Clara :listeners when I did a quick GitHub search

https://github.com/CoNarrative/precept/blob/6d919a91f846c9e5ca2d53384efe4da7981f1914/src/cljc/precept/listeners.cljc

I knew they were doing interesting things in using Clara for app state mgmt (may be saying that wrong)

Right, I stumbled across that too

they impl’ed the protocols though and included the no-ops

Probably going to have a look into their code, I like the idea of precept as well

yeah, I’ve wanted to look at that codebase sometime soon

seems like some interesting stuff

Several people have had use cases that sounded like what they were looking for was the ability to get the changes in query results relative to an earlier state, and it sounds like that sort of functionality might be what you’re looking for as well @mrchance . That could be done with some wrappers in your code around the session along the lines of “Query the session, store the results, insert/retract facts, fire the rules, then query again and diff the results”. It could be done as a Clara listener too by tracking on the listening calls in QueryNode: https://github.com/cerner/clara-rules/blob/0.15.2/src/main/clojure/clara/rules/engine.cljc#L430

It is functionality that I think would be useful for Clara itself to provide at some point, a listener to do that would probably get into Clara’s internal impl details somewhat e.g. “is this node a QueryNode?” logic. Wouldn’t matter if it was part of Clara and tested there though.

@wparker True, that's another way to look at it. This might work too. Your answer also makes me wonder if Datascript would be the better choice for this usecase though, since there you get the transaction logs anyway