You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(defrecord A [a])
(defrecord B [b])
(defrule a-rule
[A (= ?a a)]
[B (= ?r (conj b ?a))
(not-empty? ?r)]
=>
(println "doesn't matter"))
This rule will fail at compilation:
Caused by: java.lang.RuntimeException: Unable to resolve symbol: ?r in this context
The reason this occurs is because the way that the graph gets built. Currently (= ?r (conj b ?a)) is identified as a join-filter-expression therefore it makes it into the ExpressionJoinNode. (not-empty? ?r) is not identified as a dependent on the binding above, so it is added as a constraint to the AlphaNode for B. Since the AlphaNode has no binding for ?r it will fail to compile when trying to resolve the binding.
The issue seems to stem from how we determine the join-expression-filter. non-equality-unifications classifies the variable usage at the beginning, however I think that it will also need to reclassify bound-variables if it encounters a binding that is a non-equality-unification.
The text was updated successfully, but these errors were encountered:
During the implementation of the PR above, i ran across a scenario where the binding in question was not passed to the production node correctly on the CLJS side of clara. This issue will encompass that issue as well, as they are too tightly coupled to not fix both.
Given the following rule:
This rule will fail at compilation:
The reason this occurs is because the way that the graph gets built. Currently
(= ?r (conj b ?a))
is identified as ajoin-filter-expression
therefore it makes it into the ExpressionJoinNode.(not-empty? ?r)
is not identified as a dependent on the binding above, so it is added as a constraint to the AlphaNode forB
. Since the AlphaNode has no binding for?r
it will fail to compile when trying to resolve the binding.The issue seems to stem from how we determine the join-expression-filter.
non-equality-unifications classifies the variable usage at the beginning, however I think that it will also need to reclassify bound-variables if it encounters a binding that is a non-equality-unification.
The text was updated successfully, but these errors were encountered: