Removing async/await code about iter-ops

[vitaly-t]

Thank you for looking into this!

The priority here is to get rid of the async/await syntax, because it slows things down quite a bit, or at least according to some tests I did in the past.

However, the whole issue isn't really a big deal, certainly not one to justify another major change. That's why I'd prefer to leave it without making any such big change, at least presently.

I appreciate all the work you've been putting into this! And since you like good challenges, then issue #33 is certainly worth looking into. It is the most complex operator that we have, and I believe some function there is off, along with the tests for it.

[RebeccaStevens]

I'm actually kind of curious whether using callbags would be the best approach. They're super performant and might even be able to dedup a lot of commonalities between the sync and async code.

[vitaly-t]

I do not see how callbacks can be used there, since every operator is expected to return a Promise.

[RebeccaStevens]

Checkout this talk: https://www.youtube.com/watch?v=Ir9-EBbc9fg

[vitaly-t]

It would take a bit of research to see if that would even be possible to use, given this library's objectives and current function. And if it were, this issue here is about the implementation aspect, strictly. I prefer to keep it simple.

[RebeccaStevens]

I've done a bit of testing on whether using callbags would be a viable approach.

Here's how a couple of the operations would look:

export const aggregate =
    <A, R>(cb: (a: A[]) => R) =>
    async (self: Source<A, unknown>): Promise<R> =>
        cb(await asyncIterableToArray(toAsyncIterable(self)));

export const count =
    <A>(cb: (value: A, index: number) => Promise<number> | number) =>
    async (self: Source<A, unknown>): Promise<number> => {
        let count = 0;
        let index = 0;
        for await (const element of toAsyncIterable(self)) {
            const result = await cb(element, index++);
            if (result) {
                count++;
            }
        }
        return count;
    };

Of course, async/await can be removed from this code but it won't be as elegant.
Those implementations above can be used from either a sync or async starting point.
A slight performance increase for sync can be achieved with a dedicated sync version of these operations:

export const aggregateSync =
    <A, R>(cb: (a: A[]) => R) =>
    (self: Source<A, unknown>): R =>
        cb([...toIterable(self)]);

export const countSync =
    <A>(cb: (value: A, index: number) => boolean) =>
    (self: Source<A, unknown>): number => {
        let count = 0;
        let index = 0;
        for (const element of toIterable(self)) {
            const result = cb(element, index++);
            if (result) {
                count++;
            }
        }
        return count;
    };

Callbags will also allow for more power pipelines.
For example, here pipe returns a Promise<number>.

const output = await pipe(
    fromIter([1, 2, 3]),
    aggregate((arr) => {
        return arr.reduce((a, c) => a + c);
    })
);
expect(output).to.eql(6);

And with the explicit sync operator, pipe returns a number.

const output = pipe(
    fromIter([1, 2, 3]),
    aggregateSync((arr) => {
        return arr.reduce((a, c) => a + c);
    })
);
expect(output).to.eql(6);

I believe using callbags would be quite beneficial but would take a bit of work to implement (and will of course be a breaking change).

Let me know if you want me to continue to pursue this.

[vitaly-t]

Finished rewriting operator concat, merged into master.

[vitaly-t]

P.S. Oddly enough, my WebStorm UI fails to detect iterable type correctly when we have more than 2 concat parameters, as shown below... even though our own test seems to pass there.

[vitaly-t]

Version 2.3.2 now has new version of concat.

[vitaly-t]

Version 2.3.3 now has new version of defaultEmpty.