CMAScript feature suggestion: Streaming Array items through filter/map/reduce functions

I always forget to reply-all :)

---------- Forwarded message ---------
From: Gus Caplan <fluffyrobotcheese at gmail.com>
Date: Fri, Jun 21, 2019, 16:34
Subject: Re: ECMAScript feature suggestion: Streaming Array items through
filter/map/reduce functions
To: Roma Bronstein <outsidenote at gmail.com>


I'm working on a proposal that adds generalized iteration methods (most of
which are lazy). https://github.com/tc39/proposal-iterator-helpers

I believe this would solve your problem.

-Gus

On Fri, Jun 21, 2019, 16:10 Roma Bronstein <outsidenote at gmail.com> wrote:

> Thanks Oliver for the quick response.
>
> The problem for me with forEach, that it's pretty much like a for loop.
> Anything can go inside the iteration logic.
> However with filter/map/reduce/some/every functions, the intention is
> explicit.
> Also you don't need to implement basic array operations that the above
> mentioned functions already provide.
>
> For instance in my opinion writing something like:
> a.filter()
>   .map()
>   .reduce()
>
> Is much clearer and safer than:
>
> let reducedValue
> a.forEach(item => {
>   if(!<filter condition>) return
>   const mappedItem = mappingLogic(item)
>   reducedValue = reduceLogic(mappedItem)
> })
>
>
>
> On Fri, Jun 21, 2019 at 11:58 PM Oliver Dunk <oliver at oliverdunk.com>
> wrote:
>
>> This seems like a good place to share the idea, and it’s helpful that you
>> provided use cases etc.
>>
>> Is there a reason why you prefer the proposed syntax over the forEach
>> loop you mentioned? Personally I like how the forEach is easy to
>> understand, but maybe there are other examples of when the stream is useful
>> and the polyfill is much more complex.
>>
>> > On 21 Jun 2019, at 16:32, Roma Bronstein <outsidenote at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > It's my first time suggesting a feature, hope I'm doing it correctly.
>> >
>> > I really like using Array.prototype.map(), Array.prototype.reduce() and
>> all related functions.
>> > The code is more readable and it looks better.
>> > However, when I want to write performance sensitive code, chaining
>> these functions is not a good approach.
>> > For example, writing this:
>> > // a is an Array of length N
>> > const b = a.filter().map()
>> >
>> > will require 2 traversals over the whole array, up to 2*N iterations
>> (if the filter passes all items).
>> >
>> > This is why I often resort to writing this:
>> > const b= []
>> > a.forEach(() => {
>> >   if (/*the filter condition*/)
>> >     b.push(/*mapping logic*/)
>> > })
>> >
>> > Which requires only N iterations.
>> >
>> > I suggest adding a capability to streamline items to these functions.
>> > I get my inspiration from Redis's transaction syntax where you declare
>> starting a transaction and finally call EXEC in order to execute it.
>> > So now I'll be able to write something like this:
>> > const b = a.stream()
>> >   .filter()
>> >   .map()
>> >   .exec()
>> >
>> > Just to clarify the example:
>> > I've declared that I'd like to stream array items of a. Then I've
>> chained the functions I'd like to items to pass through.
>> > Finally I've activated it using the exec() function.
>> >
>> > I'm not sure if this is the best syntactical approach, but this example
>> is more intuitive to understand in my opinion.
>> >
>> > Another approach could be thinking about a "pipeline" operator like in
>> UNIX cli, providing a more generic capability to pipeline iterators.
>> >
>> > Again, I hope I'm doing this correctly and in the right forum.
>> > And if so, I'd be happy to hear some feedback.
>> >
>> > Thanks,
>> > Roma
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190621/11b5dfc4/attachment.html>

Thanks Gus.

I'm not sure I fully understand the proposal docs (first time I'm reading
something like this
<https://tc39.es/proposal-iterator-helpers/#sec-iteratorprototype-map>,
OMG...)
Can you please show a quick example of how would you streamline an array
through filter, map and then reduce?

Thanks,
Roma


On Sat, Jun 22, 2019 at 12:36 AM Gus Caplan <me at gus.host> wrote:

> I always forget to reply-all :)
>
> ---------- Forwarded message ---------
> From: Gus Caplan <fluffyrobotcheese at gmail.com>
> Date: Fri, Jun 21, 2019, 16:34
> Subject: Re: ECMAScript feature suggestion: Streaming Array items through
> filter/map/reduce functions
> To: Roma Bronstein <outsidenote at gmail.com>
>
>
> I'm working on a proposal that adds generalized iteration methods (most of
> which are lazy). https://github.com/tc39/proposal-iterator-helpers
>
> I believe this would solve your problem.
>
> -Gus
>
> On Fri, Jun 21, 2019, 16:10 Roma Bronstein <outsidenote at gmail.com> wrote:
>
>> Thanks Oliver for the quick response.
>>
>> The problem for me with forEach, that it's pretty much like a for loop.
>> Anything can go inside the iteration logic.
>> However with filter/map/reduce/some/every functions, the intention is
>> explicit.
>> Also you don't need to implement basic array operations that the above
>> mentioned functions already provide.
>>
>> For instance in my opinion writing something like:
>> a.filter()
>>   .map()
>>   .reduce()
>>
>> Is much clearer and safer than:
>>
>> let reducedValue
>> a.forEach(item => {
>>   if(!<filter condition>) return
>>   const mappedItem = mappingLogic(item)
>>   reducedValue = reduceLogic(mappedItem)
>> })
>>
>>
>>
>> On Fri, Jun 21, 2019 at 11:58 PM Oliver Dunk <oliver at oliverdunk.com>
>> wrote:
>>
>>> This seems like a good place to share the idea, and it’s helpful that
>>> you provided use cases etc.
>>>
>>> Is there a reason why you prefer the proposed syntax over the forEach
>>> loop you mentioned? Personally I like how the forEach is easy to
>>> understand, but maybe there are other examples of when the stream is useful
>>> and the polyfill is much more complex.
>>>
>>> > On 21 Jun 2019, at 16:32, Roma Bronstein <outsidenote at gmail.com>
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > It's my first time suggesting a feature, hope I'm doing it correctly.
>>> >
>>> > I really like using Array.prototype.map(), Array.prototype.reduce()
>>> and all related functions.
>>> > The code is more readable and it looks better.
>>> > However, when I want to write performance sensitive code, chaining
>>> these functions is not a good approach.
>>> > For example, writing this:
>>> > // a is an Array of length N
>>> > const b = a.filter().map()
>>> >
>>> > will require 2 traversals over the whole array, up to 2*N iterations
>>> (if the filter passes all items).
>>> >
>>> > This is why I often resort to writing this:
>>> > const b= []
>>> > a.forEach(() => {
>>> >   if (/*the filter condition*/)
>>> >     b.push(/*mapping logic*/)
>>> > })
>>> >
>>> > Which requires only N iterations.
>>> >
>>> > I suggest adding a capability to streamline items to these functions.
>>> > I get my inspiration from Redis's transaction syntax where you declare
>>> starting a transaction and finally call EXEC in order to execute it.
>>> > So now I'll be able to write something like this:
>>> > const b = a.stream()
>>> >   .filter()
>>> >   .map()
>>> >   .exec()
>>> >
>>> > Just to clarify the example:
>>> > I've declared that I'd like to stream array items of a. Then I've
>>> chained the functions I'd like to items to pass through.
>>> > Finally I've activated it using the exec() function.
>>> >
>>> > I'm not sure if this is the best syntactical approach, but this
>>> example is more intuitive to understand in my opinion.
>>> >
>>> > Another approach could be thinking about a "pipeline" operator like in
>>> UNIX cli, providing a more generic capability to pipeline iterators.
>>> >
>>> > Again, I hope I'm doing this correctly and in the right forum.
>>> > And if so, I'd be happy to hear some feedback.
>>> >
>>> > Thanks,
>>> > Roma
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190622/13cfc8f2/attachment-0001.html>