Potential regression from `lazy-seq` seq caching fix

[frenchy64]

In #322 I proposed a fix to lazy-seq not caching calls to seq.

When tried in ClojureScript a regression was found, as it made LazySeq less lazy: https://clojure.atlassian.net/browse/CLJS-3420

We should consider reverting #322 and find another fix. I made a suggestion to try in the Jira ticket, which also includes a regression test.

[cgrand]

David's regression test pass in CLJD.
@frenchy64 since you are familiar with both impls, do you have an idea why?

[frenchy64]

@cgrand Hmm I'm not sure, CLJD should stackoverflow at some point too. I think the basic problem with the original fix is the loop is no longer trampolining calling seq on nested lazy seqs. They instead stack until the stack overflows.

Could you try a couple of more aggressive ideas to reproduce?

1. Something like (first (remove any? (range))) should run forever with the correct impl. The incorrect impl will stackoverflow.
2. Measure the maximum stack size in the regression test. The incorrect implementation should increase linearly with the size of the map. A correct implementation should have a constant stack size.

[cgrand]

I reverted your change and committed this one: e66bd01#diff-7d37216e2a92d1019eb7fe5bf292430220b2fcec4cbc2cd3355c6a4226333680L3643-R3643

Any opinion on it?

Also the loop trampolining .sval calls somehow reminds me of union-find and I wonder if path-splitting or path-halving should be applied.