If :x is nil, then it’d just try to unify on nil.

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?

not= is just clj function. Not special to Clara.

= is a bit special since Clara uses it for 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

If you didn't want nil. You could add a constraint for some?

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 🙂

(defrule my-rule
  [Foo (= ?p (:x this))]
  [Bar (= ?q (:x this))]
  [:test (not= ?p ?q]
  =>
  (insert (->Baz)))

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

Your rule above looks like a contradiction.

That's why I was thinking you should avoid unification.

Unification means they are equal. Then you check them not=

I don't see how you can unify with constraints on not=

You could use negation conditions to do what you want but I'm not sure what you need from the facts that you bind

[Foo (= ?p (:x this))]
[:not [Bar (= ?q (:x this))]]

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

So not quite the same I think

Rule condition pattern is of the form

[FactType (<constraints>)]

And most things you write as constraints are regular clj functions

Unification is a little special

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

That's a common pattern. Surprised if no examples documented

Could be wrong but I had a good look in the examples too but didn't spot any.

Seems like it'd be a good addition then.

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

Though some important and typical ones like the above should be documented more.