This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (19)
- # babashka (11)
- # babashka-sci-dev (9)
- # beginners (71)
- # calva (25)
- # cider (1)
- # clara (36)
- # clj-kondo (47)
- # clojure (65)
- # clojure-dev (64)
- # clojure-europe (9)
- # clojure-nl (2)
- # clojure-seattle (1)
- # clojure-uk (2)
- # clojured (8)
- # clojurescript (17)
- # cursive (9)
- # data-science (36)
- # datahike (11)
- # emacs (10)
- # figwheel-main (19)
- # fulcro (15)
- # graalvm (12)
- # humbleui (5)
- # introduce-yourself (3)
- # jobs (10)
- # leiningen (4)
- # lsp (24)
- # malli (7)
- # nextjournal (23)
- # off-topic (1)
- # pedestal (2)
- # polylith (6)
- # portal (1)
- # re-frame (3)
- # reitit (2)
- # releases (2)
- # remote-jobs (1)
- # reveal (9)
- # shadow-cljs (13)
- # spacemacs (6)
- # xtdb (3)
Is this a valid way of looking for Foo and Bar facts that don't have the same
:x field ? Is there a "better" way?
I find it a little hard to parse the use of
(defrule my-rule [Foo (= ?x (:x this))] [Bar (not (= ?x (:x this)))] => (insert (->Baz)))
(not ...)as a piece of logic together with
(= ...)which is here only used for assignment to try and unify facts with the same
:x.... if you see what I mean? Also interested in what happens and how it should be understood when the
:xof Bar happens to be nil - which is partly what prompted this question 🙂
In terms of how to write this rule, I don’t think I immediately see an issue with what you proposed.
Actually, you may want to use
not=. I’m not sure unifying makes sense if you then wrap a
not on it. I forget if the compiler is capable of understanding this in a meaningful way. Does it behave as you expect?
Well the rule was meant to fire to show a problem when the user had supplied an (Foo)
:x which was different to the "required" (Bar)
:x , which it did - including when the supplied
:x was nil. We weren't expecting that the supplied
:x could ever be nil but that was our fault. But on trying to solve that bug I started squinting at this code and realising I didn't reallyknow why it was working at all. I must admit I wasn't aware of
not= nor can I find docs about it? Seems in theory a tricky thing to achieve - a kind of complement to unification?
So in this case I think I'd avoid the unification and just use a “clj function filter” which not= would serve the purpose
Ah ok. So I guess we should be doing this. That reads better to me as I'm not left scratching my head about whether it's unifying or not 🙂
Also I've just now come across the destructuring part of your docs and so looks like the
(defrule my-rule [Foo (= ?p (:x this))] [Bar (= ?q (:x this))] [:test (not= ?p ?q] => (insert (->Baz)))
(:x this)parts could be cleaned up too 😊
Would have to add the "some" constraint as you said. BTW I wasn't sure what you meant by "clj function filter"? (That's what had me looking in the docs again.)
You could use negation conditions to do what you want but I'm not sure what you need from the facts that you bind
However this may be a bit different than the RHS firing pattern you wanted. This would be true for every Foo that didn't have any Bar with the same :x
Rule condition pattern is of the form
I was just saying that constraints are like a “filter” over the facts of FactType
I believe when you have a top-level = in a constraint it is treated as a unifying bind. If you meat the = below something like
not in your original rendition of this, I think the unification isn't handled specially and instead the constraint expressions are just evaluated linearly across the facts of FactType like a
filter. So your original version probably did work and I misread. However I still think
not= is a bit more concise and clear and you still need the
some? check for your nil handling.
So I had never realised you could use a bound variable in ordinary LHS fact predicates before. It does say that you can in the http://www.clara-rules.org/docs/expressions/ docs page ...
... where it says "The fact type is then followed by zero or more S-expressions which can either be predicates run against a fact, or bindings, as described above." But I'm afraid I missed that.
In the same docs it also says below "If the same binding is used in multiple conditions, Clara ensures that all conditions can be satisfied with the same binding before activating the rule or query", except that it doesn't when you use it in a predicate s-expression after the fact type as described above.
There are no examples in that page of using an "earlier" (although the order doesn't matter) bound variable
?x in a predicate s-expression after the fact type such that the
?x used in there is not unified with the others. I think there perhaps should be? Been using Clara for 4 years and we've been missing out on that option for expressing rules! 🎒
A bit late here, but I'm not sure what scenario you're referring to @U3TSNPRT9 . Do you mean something like this?
`(defrule insert-cold-temperature [Temperature (= ?temperature temperature) (< ?temperature 30)] => (insert! (->Cold ?temperature)))
The code formatting doesn't seem to be working on my mobile unfortunately. Or did you mean something else?
Pretty much. I think an example where the property of one fact is directly compared to the property of another without unifying would be useful. Like ...
(defrule ice-lolly [Drink (= ?freezing-temp freezing-temp) [TempReading (< temperature ?freezing-temp)] => (insert! (->FrozenDrink))
If you look through the test-rules ns in the Clara test directory you'll probably see quite a few different rule patterns that aren't in examples