Fork me on GitHub
#clara
<
2017-09-29
>
olivergeorge00:09:28

In my early experimentation with clara I ended up with infinite loops when firing rules. They were non-terminating due to rules which are directly or indirectly affected by the facts they insert.

olivergeorge00:09:46

I went looking for documentation around this. I can't see anything apart from an issue about a :no-loop flag.

olivergeorge00:09:38

Direct question: is Clara smart enough to avoid infinite loops based on bad rules?

souenzzo12:09:56

@dadair not sure if I understand. But my rules was in a loop inside the fire-rules.

mikerod15:09:54

@olivergeorge are you asking if Clara can solve the Halting problem?

mikerod15:09:17

Joking aside: No Clara can’t really detect the loops

mikerod15:09:24

The RHS can do arbitrary things

mikerod15:09:39

There is no way to know that something that “looks like a cycle” at runtime isn’t going to eventually stop cycling

mikerod15:09:18

Clara could assume if a cycle of rules was happening “too many times” that it should stop

mikerod15:09:52

In Drools (popular Java-based rules engine that I often reference since it was used a lot in the industry) there was a “fire until halt” sort of method I believe it was called. This allowed to have a sort of “timeout” feature that the rules would stop if they reached a certain threshold of time, steps, # rule firings, etc. So something like that is feasible to implement, but not in Clara right now.

mikerod15:09:45

I do tend to try to avoid using something like :no-loop too and instead setup the rules in a way where they logically won’t loop. :no-loop starts to go against the logical truth maintenance in some cases.

mikerod15:09:23

Understandably, there are cases where it is sort of hard to think about how you can make the rule logic you want not form a logical loop.

wparker15:09:13

There is work logged for Clara to assume by default that after a certain number of iterations of looping that the rules were written incorrectly and throw an exception: https://github.com/cerner/clara-rules/issues/275

wparker16:09:21

I agree with @mikerod ‘s comments - perhaps another way of thinking about it is that if you just write a normal infinitely recursive function, Clojure or any other programming language can throw a StackOverflowException but can’t automatically recover from it - the language would have to guess what the programmer actually wanted to do in order to accomplish that

wparker16:09:26

I see Clara’s handling of infinitely looping rules as similar - there’s no way for Clara to guess what the user actually wanted to do

mikerod16:09:40

Cool, forgot you logged that issue before

dadair21:09:30

Is there a way for someone to override what is printed when an exception is thrown? I have a fact with a very large map and when an exception is thrown it tries to print it as a binding and the REPL basically becomes unresponsive.

mikerod22:09:26

@dadair I’ve had similar issues before

mikerod22:09:39

Trying to think of a workaround

mikerod22:09:25

I think printing the bindings directly in the exception message can be a little ambitious since sometimes there are really large bindings. They can be really big due to things like acc/all too

mikerod22:09:41

From the REPL, you may be able to get by with try + catch around when you run the rules?

mikerod22:09:55

so catch the exception to not let it print its default dump

mikerod22:09:18

if you are encountering the error using something like clojure.test it automatically catches and prints exceptions I think. You may be able to override that behavior as well