Hmm, might be, I'll play around with it a bit and ...

# arrow-contributors

[Jannis]

Hmm, might be, I'll play around with it a bit and see what I need to do to get it working 👍

[raulraja]

thanks!

[Jannis]

This is a stdlib bug. Either that or I am misunderstanding plus.

// all methods are stdlib
(1..10000).asSequence().fold(emptySequence<Int>()) { acc, el ->
        acc + el
      }.first()

Also fails with a stackoverflow. Fold on its own is perfectly fine. First on infinite sequences is as well. That leaves only plus as the culprit. Either way, defining sequence methods that are refolds from sequence to sequence should not be done using fold in the first place as that forces the entire sequence

[raulraja]

Is foldRight stack safe?

[Jannis]

Yes, due to eval it should be. Will try that next

[Jannis]

Well it becomes really really slow, because it evaluates the entire thing first and eval just slows stuff down... I don't think it'll change the outcome tho as the fold is perfectly fine unless it's building a new sequence using plus

[Jannis]

So after this finally ran through: foldRight is the same. I still think it's plus. But anyway, imo there is no point fixing that particular problem as the whole implementation map().fold() is just wrong to begin with, at least on sequences it is. This should be gone when not folding the whole thing for a simple filter

[Jannis]

Should also be no api changes, so I think thats the best way forward

[raulraja]

sounds great