Seqs get caching behaviour & API

[chenglou]

Edit: Sorry, didn't see the cacheResult function, so turning this into a new issue.

Clojure auto caches seq.get(i). I think this is a better solution than to either explicitly call cacheResult or never cache, for 2 reasons:

• It's not clear that the last line is always linear:

var s = I.Range(0, 10);
var c = s.skipWhile(function(v, i) {
  console.log(i);
  return i < 5;
});

c.first(); // logs 0 1 2 3 4 5, each time

• cacheResult force evaluates the whole seq which kinda defeats the purpose of lazy evaluation (I can't use it, my stream is infinite). I think clojure's "cache as you go" approach is much better, whether we make the caching explicit or not (I'm for the latter).

[leebyron]

Good suggestion. I think default to no cache is still best to make chaining operations easier to build, but a cacheGets could be pretty interesting

[hleumas]

@leebyron what do you mean by

I think default to no cache is still best to make chaining operations easier to build, but a cacheGets could be pretty interesting

How does it make chaining operations easier?

Also, what is the difference between calling cacheResult and toList ? Is there any particular reason why should I prefer the former?

Would you be interested in pull request doing auto-cache of Seq as it gets lazy evaluated?

[leebyron]

I would be happy to look at that PR!

[hleumas]

Great! I will work on it.

[jareware]

Just spent the better part of an hour scratching my head with a Heisenbug caused by this... or rather, by my assumption that it worked the same as in Clojure. :)

👍 for auto-caching Seq's!

I also don't quite get this part in the docs:

Because Sequences are lazy and designed to be chained together, they do not cache their results.

[lacker]

Sounds like the discussion in this issue has concluded so I am going to close it. Thanks folks!

[gabejohnson]

@lacker Is there a follow-up discussion somewhere? Implicit auto-caching is still a missing feature.