release 2

[xgbuils]

I would like to do some breaking changes.

First of all, I prefer that methods that returns lazy iterables of arrays (zip, cartesian, permutations) return iterables of iterables to achieve a real laziness. For example, is not possible to do permutations or cartesian product of potentially infinite iterables.

At second point, I want to use memoization. For example, if we have:

const iterable = Iterum([1, 2, 4, 8, 16, 32, 64, 128])

and then we need to do:

const slice = iterable.slice(6)
const result = slice.concat(slice)
[...result]

The first iterable is traversed twice.

I don't want this behaviour.

Finally, there are some methods like map, reduce, every, etc. that I would like to simplify thus:

1. removing the context parameter and,
2. Allowing the value parameter on callback functions.

The reason is that point 1 can be acomplished using bind and point 2 can be achieved using zip combined with other methods. For example:

const iterable = Iterum([1, 3, 5, 7]).map((e, i) => 2 * e + i)
// would be implemented thus:
const {range} = Iterum
const iterable = Iterum([1, 3, 5, 7]).zip(range(0, Infinity)).map(([e, i]) => 2 * e + i)

[xgbuils]

I created a new package iterarray with a tiny API (slice & nth) to achieve better performance with sliced iterables, caching values and taking advantage of performance when iterables that are passed are indexables.

I going to use iterarray as a dependency of iterum to bring better performance and simplify some methods.

[benji6]

If possible are you able to collect some benchmarks on the new approach using iterarray?

I've been thinking about performance a lot in imlazy and am pretty stoked that it seems to be running faster than native array methods now in node 8! I decided against a caching approach though because in theory a user should be able to pull from an infinite iterable without ever having to worry about memory running out... What if they want to take some values from an infinite iterable every time an event occurs and the code is running for a long time on a tiny node machine? Will it fall over eventually? It's something of a niche use-case but naive caching does introduce that risk... Would be good to see what perf gains you make with it though

[xgbuils]

Hi @benji6!

It sounds good. I will collect some benchmarks on the last 1.x version and 2.0 version to contrast that.

My idea of iterarray package is:

• to have nth(n) with O(1) amortized cost (the first call with O(n) cost, the next calls with O(1))
• to keep .slice with O(1) cost
• to traverse slice(m, n) with O(m - n) amortized cost (the first time with O(n) and the next times with O(n - m)).

But certainly, achieving this can produce memory issues. I should think on this.

Thanks so much!

[benji6]

No worries, really interesting to see what you're getting up to here!