clara

http://www.clara-rules.org/
cfleming 2018-01-08T00:32:42.000003Z

In the docs, there’s an example rule:

(defrule get-windspeeds-from-location
  [?temp <- [Temperature (= ?location location)]]
  [?wind <- (acc/all) :from [WindSpeed (= ?location location)]]
  =>
  ;; do something
)

cfleming 2018-01-08T00:33:22.000117Z

Am I correct in thinking that the first condition should actually be [?temp <- Temperature (= ?location location)], i.e. with no nested vectors?

alex-dixon 2018-01-08T00:44:53.000111Z

It can be either insofar as I know

alex-dixon 2018-01-08T00:46:38.000084Z

@cfleming I have some changes that I’m not totally happy with that try to accommodate that

alex-dixon 2018-01-08T01:11:45.000070Z

Oops. Looks like that would entail an “extraneous vcector error”

2018-01-08T01:11:47.000155Z

@alex-dixon @cfleming I think the first condition of that rule is incorrect

2018-01-08T01:12:35.000003Z

There shouldn’t be a vector around Temperature in the non-accumulator case. What @cfleming said is right on that one.

2018-01-08T01:12:50.000072Z

If Clara accepts it. I think it would be with the wrong semantics.

cfleming 2018-01-08T01:12:54.000045Z

Great, thanks Mike

alex-dixon 2018-01-08T01:13:00.000065Z

[?order <- [WorkOrder (= ?clientid clientid)
              (= scale :big)
              (< (days-between requestdate duedate) 14)]]
=>
CompilerException clojure.lang.ExceptionInfo: Type [WorkOrder (= ?clientid clientid) (= scale :big) (< (days-between requestdate duedate) 14)] is a vector and appears to contain expressions. Is there an extraneous set of brackets in the condition? 

2018-01-08T01:13:35.000030Z

It’d consider the whole thing to be the “fact type”. Which is related to the issue of ambiguity of syntax when you allow any arbitrary structure for a fact type. We discussed this on some issue recently

cfleming 2018-01-08T01:13:43.000127Z

As the unofficial ranter about macro error messages, that’s a very nice message indeed.

👍 2
2018-01-08T01:14:15.000076Z

Oh nice. Yeah I guess that case was special cased. Due to it being fairly easy to mistakenly do

2018-01-08T15:51:42.000153Z

@mikerod I haven’t gotten around to doing a comprehensive writeup, but basically I was looking at how to address https://github.com/cerner/clara-rules/issues/343 and ran into what I think are some issues with to-dnf. Basically since the :or operation is actually more of a union in the set theory sense, I think the to-dnf transforms can end up messing with cardinality. For example, [:not [:and A B]] is equivalent to [:or [:not A] [:not B]] in a boolean sense, but the second can match twice and the first can’t in the context of Clara.

✅ 1
2018-01-08T16:12:57.000174Z

@wparker thanks. I remember the topic better now.