rbrush/clara-rules — pull request #59 by mrrodriguez (2014-06-18 02:28:06+00:00)
Title: Fix potential StackOverflowError when many elements/tokens/activations added to working memory

There is potential for a `StackOverflowError` to be thrown in a few scenarios:
1. A large number of elements are added via `clara.rules.memory/add-elements!` from right activations.
2. A large number of tokens are added via `c.r.m/add-tokens!` from left activations.
3. A large number of activations are added via `c.r.m/add-activations!` from rule activations.

The reason for this is that these `add-*!` functions are "piling" up successive calls to `concat`, which is lazy.
When this seq of `concat`ed elements is realized, it needs _n_ number of stack frames to get the first (and successive) element(s) , where _n_ is the "large number of elements/tokens/activations added via" an `add-*!` function.

This looks something like (example from `add-elements!`):
```clj
(concat previous-elements elements)

```

The most obvious solution to this problem is to swap the `concat` with a `into` instead, which is eagerly evaluated.
However, it is worth considering if the eager evaluation of `into` is appropriate. Is there a good reason to perform these operations in a lazy manner? It is not immediately clear to me.

**Also, note that `c.r.m/add-insertions!` has the same nested `concat` call structure in it. However, I have not reproduced this in a test case yet. I believe it may need to be addressed in the same way as the 3 places addressed in this issue. I have left it alone currently.**

Issues like this have been discussed in a number of different threads, but http://stackoverflow.com/questions/5294055/why-am-i-getting-a-stackoverflow is one example.

In my test cases, I have set the addition count `n` to 6000. Around ~4K additions to memory is where the StackOverflowError comes up (i.e. whatever the call-stack limitation is).

I've written tests to expose the 3 points above. I have noted that using batch insertions in these test cases, could workaround the issue. However, I'm not sure that the memory should be implemented in a way that relies on the rules using batch insertions in all cases where there may be a lot of added elements/tokens/activations.