Re: syntax for case ranges

[Jordan Harband]

@kdex (sorry i missed this; your message was in my spam folder) if you find
a way that Annex E is non-exhaustive, please file an issue on the spec - I
would like it to be exhaustive.

On Mon, Feb 3, 2020 at 11:16 AM Naveen Chawla  wrote:

> Thanks! Although I think it is a value judgement about how much risk is
> worth how much reward, and which reward, so I wouldn't classify it as
> necessarily a complete set of criteria yet, but it is certainly in the
> right direction. And very interesting to me. Thank you.
>
> On Tue, 4 Feb 2020 at 00:40, Mark S. Miller  wrote:
>
>> While correct, each case asked the browser makers to make a risky and
>> costly bet. When the risk was low and the payoff high, they've been great
>> at doing so. This one does not fall into the viable risk vs reward
>> territory.
>>
>>
>> On Mon, Feb 3, 2020 at 7:58 AM kdex  wrote:
>>
>>> Yes, there have been numerous backwards-incompatible changes to the
>>> language
>>> over the years.
>>>
>>> You can find a list of them in section E of the ECMAScript language
>>> standard.
>>> IIRC, that list is non-exhaustive.
>>>
>>> On Monday, February 3, 2020 6:35:12 PM CET Naveen Chawla wrote:
>>> > Thank you Claude! I did miss the point.
>>> >
>>> > Have there ever been "BC" breaks introduced into the language before?
>>> If
>>> > so, is there a sustainable standard for an "acceptable" one?
>>> >
>>> > On Mon, 3 Feb 2020 at 22:47, Claude Pache 
>>> wrote:
>>> > > Try typing `3 < 2 < 1` in the web console of your favourite browser,
>>> and
>>> > > see the result: it will evaluate to `true`. No, your browser isn’t
>>> buggy,
>>> > > it is just following blindly the semantics of `<`.
>>> > >
>>> > > Modifying the meaning of `3 < 2 < 1` in order to make it evaluating
>>> to
>>> > > `false` is a BC break. Is it acceptable? Dunno.
>>> > >
>>> > > —Claude
>>> > >
>>> > > Le 3 févr. 2020 à 15:23, Naveen Chawla  a
>>> écrit :
>>> > >
>>> > > Hi!
>>> > >
>>> > > I didn't understand your reply.
>>> > >
>>> > > I think currently it would raise an error, because 1 < 2 < 3 is
>>> currently
>>> > > saying (probably) true < 3.
>>> > >
>>> > > But a "new" syntax could possibly parse that as a "chain" of
>>> comparisons.
>>> > >
>>> > > Would this be acceptable to introduce into JavaScript (just curious)?
>>> > >
>>> > > I've probably missed your point entirely, because I saw a short
>>> message "3
>>> > > < 2 < 1 //true", and I've assumed you meant it in reverse.
>>> > >
>>> > > On Sat, 1 Feb 2020 at 23:12, Mark S. Miller 
>>> wrote:
>>> > >> 3 < 2 < 1;  // true
>>> > >>
>>> > >>
>>> > >> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla >> >
>>> > >>
>>> > >> wrote:
>>> > >>> Certain languages allow the expression 0>> this
>>> > >>> would be syntactically possible in JavaScript? Of course this
>>> would only
>>> > >>> apply for "if"/"while" statements.
>>> > >>>
>>> > >>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows <
>>> cont...@isiahmeadows.com>
>>> > >>>
>>> > >>> wrote:
>>> > >>>> Still better to discuss it there - it's highly related to your
>>> > >>>> suggestion. And I'm pretty sure an issue already exists related to
>>> > >>>> that.
>>> > >>>>
>>> > >>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>>> > >>>>> The pattern matching proposal does not handles the mentioned
>>> case:
>>> > >>>>>
>>> > >>>>> switch(type) { case 0...5: } being the equivalent of
>>> switch(type) {
>>> > >>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
>>> > >>>>>
>>> > >>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
>>> > >>>>>
>>> > >>>>

Re: syntax for case ranges

[Naveen Chawla]

Thanks! Although I think it is a value judgement about how much risk is
worth how much reward, and which reward, so I wouldn't classify it as
necessarily a complete set of criteria yet, but it is certainly in the
right direction. And very interesting to me. Thank you.

On Tue, 4 Feb 2020 at 00:40, Mark S. Miller  wrote:

> While correct, each case asked the browser makers to make a risky and
> costly bet. When the risk was low and the payoff high, they've been great
> at doing so. This one does not fall into the viable risk vs reward
> territory.
>
>
> On Mon, Feb 3, 2020 at 7:58 AM kdex  wrote:
>
>> Yes, there have been numerous backwards-incompatible changes to the
>> language
>> over the years.
>>
>> You can find a list of them in section E of the ECMAScript language
>> standard.
>> IIRC, that list is non-exhaustive.
>>
>> On Monday, February 3, 2020 6:35:12 PM CET Naveen Chawla wrote:
>> > Thank you Claude! I did miss the point.
>> >
>> > Have there ever been "BC" breaks introduced into the language before? If
>> > so, is there a sustainable standard for an "acceptable" one?
>> >
>> > On Mon, 3 Feb 2020 at 22:47, Claude Pache 
>> wrote:
>> > > Try typing `3 < 2 < 1` in the web console of your favourite browser,
>> and
>> > > see the result: it will evaluate to `true`. No, your browser isn’t
>> buggy,
>> > > it is just following blindly the semantics of `<`.
>> > >
>> > > Modifying the meaning of `3 < 2 < 1` in order to make it evaluating
>> to
>> > > `false` is a BC break. Is it acceptable? Dunno.
>> > >
>> > > —Claude
>> > >
>> > > Le 3 févr. 2020 à 15:23, Naveen Chawla  a
>> écrit :
>> > >
>> > > Hi!
>> > >
>> > > I didn't understand your reply.
>> > >
>> > > I think currently it would raise an error, because 1 < 2 < 3 is
>> currently
>> > > saying (probably) true < 3.
>> > >
>> > > But a "new" syntax could possibly parse that as a "chain" of
>> comparisons.
>> > >
>> > > Would this be acceptable to introduce into JavaScript (just curious)?
>> > >
>> > > I've probably missed your point entirely, because I saw a short
>> message "3
>> > > < 2 < 1 //true", and I've assumed you meant it in reverse.
>> > >
>> > > On Sat, 1 Feb 2020 at 23:12, Mark S. Miller 
>> wrote:
>> > >> 3 < 2 < 1;  // true
>> > >>
>> > >>
>> > >> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
>> > >>
>> > >> wrote:
>> > >>> Certain languages allow the expression 0> this
>> > >>> would be syntactically possible in JavaScript? Of course this would
>> only
>> > >>> apply for "if"/"while" statements.
>> > >>>
>> > >>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows <
>> cont...@isiahmeadows.com>
>> > >>>
>> > >>> wrote:
>> > >>>> Still better to discuss it there - it's highly related to your
>> > >>>> suggestion. And I'm pretty sure an issue already exists related to
>> > >>>> that.
>> > >>>>
>> > >>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>> > >>>>> The pattern matching proposal does not handles the mentioned case:
>> > >>>>>
>> > >>>>> switch(type) { case 0...5: } being the equivalent of switch(type)
>> {
>> > >>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
>> > >>>>>
>> > >>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
>> > >>>>>
>> > >>>>> bruno.macab...@gmail.com> wrote:
>> > >>>>>> I agree with Oriol.
>> > >>>>>> We already have the proposal pattern matching, that has a very
>> > >>>>>> similar effect.
>> > >>>>>> I think that is better to improve pattern matching proposal in
>> order
>> > >>>>>> to be able to match using ranges (or at least check if it's good
>> to
>> > >>>>>> do)
>> > >>>>>> instead of create a new proposal.
>> > >>>>>>
>> > >&g

Re: syntax for case ranges

[Mark S. Miller]

While correct, each case asked the browser makers to make a risky and
costly bet. When the risk was low and the payoff high, they've been great
at doing so. This one does not fall into the viable risk vs reward
territory.


On Mon, Feb 3, 2020 at 7:58 AM kdex  wrote:

> Yes, there have been numerous backwards-incompatible changes to the
> language
> over the years.
>
> You can find a list of them in section E of the ECMAScript language
> standard.
> IIRC, that list is non-exhaustive.
>
> On Monday, February 3, 2020 6:35:12 PM CET Naveen Chawla wrote:
> > Thank you Claude! I did miss the point.
> >
> > Have there ever been "BC" breaks introduced into the language before? If
> > so, is there a sustainable standard for an "acceptable" one?
> >
> > On Mon, 3 Feb 2020 at 22:47, Claude Pache 
> wrote:
> > > Try typing `3 < 2 < 1` in the web console of your favourite browser,
> and
> > > see the result: it will evaluate to `true`. No, your browser isn’t
> buggy,
> > > it is just following blindly the semantics of `<`.
> > >
> > > Modifying the meaning of `3 < 2 < 1` in order to make it evaluating  to
> > > `false` is a BC break. Is it acceptable? Dunno.
> > >
> > > —Claude
> > >
> > > Le 3 févr. 2020 à 15:23, Naveen Chawla  a
> écrit :
> > >
> > > Hi!
> > >
> > > I didn't understand your reply.
> > >
> > > I think currently it would raise an error, because 1 < 2 < 3 is
> currently
> > > saying (probably) true < 3.
> > >
> > > But a "new" syntax could possibly parse that as a "chain" of
> comparisons.
> > >
> > > Would this be acceptable to introduce into JavaScript (just curious)?
> > >
> > > I've probably missed your point entirely, because I saw a short
> message "3
> > > < 2 < 1 //true", and I've assumed you meant it in reverse.
> > >
> > > On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  wrote:
> > >> 3 < 2 < 1;  // true
> > >>
> > >>
> > >> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
> > >>
> > >> wrote:
> > >>> Certain languages allow the expression 0 this
> > >>> would be syntactically possible in JavaScript? Of course this would
> only
> > >>> apply for "if"/"while" statements.
> > >>>
> > >>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows <
> cont...@isiahmeadows.com>
> > >>>
> > >>> wrote:
> > >>>> Still better to discuss it there - it's highly related to your
> > >>>> suggestion. And I'm pretty sure an issue already exists related to
> > >>>> that.
> > >>>>
> > >>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
> > >>>>> The pattern matching proposal does not handles the mentioned case:
> > >>>>>
> > >>>>> switch(type) { case 0...5: } being the equivalent of switch(type) {
> > >>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
> > >>>>>
> > >>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
> > >>>>>
> > >>>>> bruno.macab...@gmail.com> wrote:
> > >>>>>> I agree with Oriol.
> > >>>>>> We already have the proposal pattern matching, that has a very
> > >>>>>> similar effect.
> > >>>>>> I think that is better to improve pattern matching proposal in
> order
> > >>>>>> to be able to match using ranges (or at least check if it's good
> to
> > >>>>>> do)
> > >>>>>> instead of create a new proposal.
> > >>>>>>
> > >>>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _  >
> > >>>>>>
> > >>>>>> wrote:
> > >>>>>>> This sounds like
> https://github.com/tc39/proposal-pattern-matching
> > >>>>>>>
> > >>>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
> > >>>>>>>
> > >>>>>>> For example, the following:
> > >>>>>>>
> > >>>>>>> switch (value) {
> > >>>>>>>
> > >>>>>>> case 0...9: break
> > >>>&g

Re: syntax for case ranges

[kdex]

Yes, there have been numerous backwards-incompatible changes to the language 
over the years.

You can find a list of them in section E of the ECMAScript language standard. 
IIRC, that list is non-exhaustive.

On Monday, February 3, 2020 6:35:12 PM CET Naveen Chawla wrote:
> Thank you Claude! I did miss the point.
> 
> Have there ever been "BC" breaks introduced into the language before? If
> so, is there a sustainable standard for an "acceptable" one?
> 
> On Mon, 3 Feb 2020 at 22:47, Claude Pache  wrote:
> > Try typing `3 < 2 < 1` in the web console of your favourite browser, and
> > see the result: it will evaluate to `true`. No, your browser isn’t buggy,
> > it is just following blindly the semantics of `<`.
> > 
> > Modifying the meaning of `3 < 2 < 1` in order to make it evaluating  to
> > `false` is a BC break. Is it acceptable? Dunno.
> > 
> > —Claude
> > 
> > Le 3 févr. 2020 à 15:23, Naveen Chawla  a écrit :
> > 
> > Hi!
> > 
> > I didn't understand your reply.
> > 
> > I think currently it would raise an error, because 1 < 2 < 3 is currently
> > saying (probably) true < 3.
> > 
> > But a "new" syntax could possibly parse that as a "chain" of comparisons.
> > 
> > Would this be acceptable to introduce into JavaScript (just curious)?
> > 
> > I've probably missed your point entirely, because I saw a short message "3
> > < 2 < 1 //true", and I've assumed you meant it in reverse.
> > 
> > On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  wrote:
> >> 3 < 2 < 1;  // true
> >> 
> >> 
> >> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
> >> 
> >> wrote:
> >>> Certain languages allow the expression 0 >>> would be syntactically possible in JavaScript? Of course this would only
> >>> apply for "if"/"while" statements.
> >>> 
> >>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows 
> >>> 
> >>> wrote:
> >>>> Still better to discuss it there - it's highly related to your
> >>>> suggestion. And I'm pretty sure an issue already exists related to
> >>>> that.
> >>>> 
> >>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
> >>>>> The pattern matching proposal does not handles the mentioned case:
> >>>>> 
> >>>>> switch(type) { case 0...5: } being the equivalent of switch(type) {
> >>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
> >>>>> 
> >>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
> >>>>> 
> >>>>> bruno.macab...@gmail.com> wrote:
> >>>>>> I agree with Oriol.
> >>>>>> We already have the proposal pattern matching, that has a very
> >>>>>> similar effect.
> >>>>>> I think that is better to improve pattern matching proposal in order
> >>>>>> to be able to match using ranges (or at least check if it's good to
> >>>>>> do)
> >>>>>> instead of create a new proposal.
> >>>>>> 
> >>>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _ 
> >>>>>> 
> >>>>>> wrote:
> >>>>>>> This sounds like https://github.com/tc39/proposal-pattern-matching
> >>>>>>> 
> >>>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
> >>>>>>> 
> >>>>>>> For example, the following:
> >>>>>>> 
> >>>>>>> switch (value) {
> >>>>>>> 
> >>>>>>> case 0...9: break
> >>>>>>> case 'a'...'z': break
> >>>>>>> 
> >>>>>>> }
> >>>>>>> 
> >>>>>>> 
> >>>>>>> ___
> >>>>>>> es-discuss mailing
> >>>>>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-disc
> >>>>>>> uss
> >>>>>>> 
> >>>>>>> 
> >>>>>>> ___
> >>>>>>> es-discuss mailing list
> >>>>>>> es-discuss@mozilla.org
> >>>>>>> https://mail.mozilla.org/listinfo/es-discuss
> >>>>>> 
> >>>>>> ___
> >>>>>> es-discuss mailing list
> >>>>>> es-discuss@mozilla.org
> >>>>>> https://mail.mozilla.org/listinfo/es-discuss
> >>>>> 
> >>>>> ___
> >>>>> es-discuss mailing list
> >>>>> es-discuss@mozilla.org
> >>>>> https://mail.mozilla.org/listinfo/es-discuss
> >>>> 
> >>>> --
> >>>> -
> >>>> 
> >>>> Isiah Meadows
> >>>> cont...@isiahmeadows.com
> >>>> www.isiahmeadows.com
> >>>> ___
> >>>> es-discuss mailing list
> >>>> es-discuss@mozilla.org
> >>>> https://mail.mozilla.org/listinfo/es-discuss
> >>> 
> >>> ___
> >>> es-discuss mailing list
> >>> es-discuss@mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >> 
> >> --
> >> 
> >>   Cheers,
> >>   --MarkM
> > 
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Naveen Chawla]

Thank you Claude! I did miss the point.

Have there ever been "BC" breaks introduced into the language before? If
so, is there a sustainable standard for an "acceptable" one?



On Mon, 3 Feb 2020 at 22:47, Claude Pache  wrote:

> Try typing `3 < 2 < 1` in the web console of your favourite browser, and
> see the result: it will evaluate to `true`. No, your browser isn’t buggy,
> it is just following blindly the semantics of `<`.
>
> Modifying the meaning of `3 < 2 < 1` in order to make it evaluating  to
> `false` is a BC break. Is it acceptable? Dunno.
>
> —Claude
>
> Le 3 févr. 2020 à 15:23, Naveen Chawla  a écrit :
>
> Hi!
>
> I didn't understand your reply.
>
> I think currently it would raise an error, because 1 < 2 < 3 is currently
> saying (probably) true < 3.
>
> But a "new" syntax could possibly parse that as a "chain" of comparisons.
>
> Would this be acceptable to introduce into JavaScript (just curious)?
>
> I've probably missed your point entirely, because I saw a short message "3
> < 2 < 1 //true", and I've assumed you meant it in reverse.
>
> On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  wrote:
>
>> 3 < 2 < 1;  // true
>>
>>
>> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
>> wrote:
>>
>>> Certain languages allow the expression 0>> would be syntactically possible in JavaScript? Of course this would only
>>> apply for "if"/"while" statements.
>>>
>>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows 
>>> wrote:
>>>
>>>> Still better to discuss it there - it's highly related to your
>>>> suggestion. And I'm pretty sure an issue already exists related to that.
>>>>
>>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>>>>
>>>>> The pattern matching proposal does not handles the mentioned case:
>>>>>
>>>>> switch(type) { case 0...5: } being the equivalent of switch(type) {
>>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
>>>>>
>>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
>>>>> bruno.macab...@gmail.com> wrote:
>>>>>
>>>>>> I agree with Oriol.
>>>>>> We already have the proposal pattern matching, that has a very
>>>>>> similar effect.
>>>>>> I think that is better to improve pattern matching proposal in order
>>>>>> to be able to match using ranges (or at least check if it's good to do)
>>>>>> instead of create a new proposal.
>>>>>>
>>>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _ 
>>>>>> wrote:
>>>>>>
>>>>>>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>>>>>>
>>>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>>>>>>
>>>>>>> For example, the following:
>>>>>>>
>>>>>>> switch (value) {
>>>>>>> case 0...9: break
>>>>>>> case 'a'...'z': break
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> es-discuss mailing 
>>>>>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss@mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>> ___
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> --
>>>> -
>>>>
>>>> Isiah Meadows
>>>> cont...@isiahmeadows.com
>>>> www.isiahmeadows.com
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> --
>>   Cheers,
>>   --MarkM
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Isiah Meadows]

Does make me wonder if engines should start collecting statistics on how
often it's used and how often that result differs from if a Python-style
chained comparison was done instead.

On Mon, Feb 3, 2020 at 09:18 Claude Pache  wrote:

> Try typing `3 < 2 < 1` in the web console of your favourite browser, and
> see the result: it will evaluate to `true`. No, your browser isn’t buggy,
> it is just following blindly the semantics of `<`.
>
> Modifying the meaning of `3 < 2 < 1` in order to make it evaluating  to
> `false` is a BC break. Is it acceptable? Dunno.
>
> —Claude
>
> Le 3 févr. 2020 à 15:23, Naveen Chawla  a écrit :
>
> Hi!
>
> I didn't understand your reply.
>
> I think currently it would raise an error, because 1 < 2 < 3 is currently
> saying (probably) true < 3.
>
> But a "new" syntax could possibly parse that as a "chain" of comparisons.
>
> Would this be acceptable to introduce into JavaScript (just curious)?
>
> I've probably missed your point entirely, because I saw a short message "3
> < 2 < 1 //true", and I've assumed you meant it in reverse.
>
> On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  wrote:
>
>> 3 < 2 < 1;  // true
>>
>>
>> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
>> wrote:
>>
>>> Certain languages allow the expression 0>> would be syntactically possible in JavaScript? Of course this would only
>>> apply for "if"/"while" statements.
>>>
>>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows 
>>> wrote:
>>>
>>>> Still better to discuss it there - it's highly related to your
>>>> suggestion. And I'm pretty sure an issue already exists related to that.
>>>>
>>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>>>>
>>>>> The pattern matching proposal does not handles the mentioned case:
>>>>>
>>>>> switch(type) { case 0...5: } being the equivalent of switch(type) {
>>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
>>>>>
>>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
>>>>> bruno.macab...@gmail.com> wrote:
>>>>>
>>>>>> I agree with Oriol.
>>>>>> We already have the proposal pattern matching, that has a very
>>>>>> similar effect.
>>>>>> I think that is better to improve pattern matching proposal in order
>>>>>> to be able to match using ranges (or at least check if it's good to do)
>>>>>> instead of create a new proposal.
>>>>>>
>>>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _ 
>>>>>> wrote:
>>>>>>
>>>>>>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>>>>>>
>>>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>>>>>>
>>>>>>> For example, the following:
>>>>>>>
>>>>>>> switch (value) {
>>>>>>> case 0...9: break
>>>>>>> case 'a'...'z': break
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> es-discuss mailing 
>>>>>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss@mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>> ___
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> --
>>>> -
>>>>
>>>> Isiah Meadows
>>>> cont...@isiahmeadows.com
>>>> www.isiahmeadows.com
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> --
>>   Cheers,
>>   --MarkM
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-- 
-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Claude Pache]

Try typing `3 < 2 < 1` in the web console of your favourite browser, and see 
the result: it will evaluate to `true`. No, your browser isn’t buggy, it is 
just following blindly the semantics of `<`.

Modifying the meaning of `3 < 2 < 1` in order to make it evaluating  to `false` 
is a BC break. Is it acceptable? Dunno.

—Claude

> Le 3 févr. 2020 à 15:23, Naveen Chawla  a écrit :
> 
> Hi!
> 
> I didn't understand your reply.
> 
> I think currently it would raise an error, because 1 < 2 < 3 is currently 
> saying (probably) true < 3.
> 
> But a "new" syntax could possibly parse that as a "chain" of comparisons.
> 
> Would this be acceptable to introduce into JavaScript (just curious)?
> 
> I've probably missed your point entirely, because I saw a short message "3 < 
> 2 < 1 //true", and I've assumed you meant it in reverse.
> 
> On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  <mailto:erig...@gmail.com>> wrote:
> 3 < 2 < 1;  // true
> 
> 
> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla  <mailto:naveen.c...@gmail.com>> wrote:
> Certain languages allow the expression 0 be syntactically possible in JavaScript? Of course this would only apply for 
> "if"/"while" statements.
> 
> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows  <mailto:cont...@isiahmeadows.com>> wrote:
> Still better to discuss it there - it's highly related to your suggestion. 
> And I'm pretty sure an issue already exists related to that.
> 
> On Fri, Jan 31, 2020 at 09:06 Sultan  <mailto:thysul...@gmail.com>> wrote:
> The pattern matching proposal does not handles the mentioned case:
> 
> switch(type) { case 0...5: } being the equivalent of switch(type) { case 0: 
> case 1: case 2: case 3: case 4: case 5: }
> 
> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus  <mailto:bruno.macab...@gmail.com>> wrote:
> I agree with Oriol.
> We already have the proposal pattern matching, that has a very similar effect.
> I think that is better to improve pattern matching proposal in order to be 
> able to match using ranges (or at least check if it's good to do) instead of 
> create a new proposal.
> 
> On Fri, 31 Jan 2020 at 14:08, Oriol _  <mailto:oriol-bugzi...@hotmail.com>> wrote:
> This sounds like https://github.com/tc39/proposal-pattern-matching 
> <https://github.com/tc39/proposal-pattern-matching>
> 
> El 31/1/20 a les 10:57, Sultan ha escrit:
>> For example, the following:
>> 
>> switch (value) {
>> case 0...9: break
>> case 'a'...'z': break
>> }
>> 
>> 
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss 
>> <https://mail.mozilla.org/listinfo/es-discuss>
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> -- 
> -
> 
> Isiah Meadows
> cont...@isiahmeadows.com <mailto:cont...@isiahmeadows.com>
> www.isiahmeadows.com 
> <http://www.isiahmeadows.com/>___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> -- 
>   Cheers,
>   --MarkM
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Naveen Chawla]

Hi!

I didn't understand your reply.

I think currently it would raise an error, because 1 < 2 < 3 is currently
saying (probably) true < 3.

But a "new" syntax could possibly parse that as a "chain" of comparisons.

Would this be acceptable to introduce into JavaScript (just curious)?

I've probably missed your point entirely, because I saw a short message "3
< 2 < 1 //true", and I've assumed you meant it in reverse.

On Sat, 1 Feb 2020 at 23:12, Mark S. Miller  wrote:

> 3 < 2 < 1;  // true
>
>
> On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla 
> wrote:
>
>> Certain languages allow the expression 0> would be syntactically possible in JavaScript? Of course this would only
>> apply for "if"/"while" statements.
>>
>> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows 
>> wrote:
>>
>>> Still better to discuss it there - it's highly related to your
>>> suggestion. And I'm pretty sure an issue already exists related to that.
>>>
>>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>>>
>>>> The pattern matching proposal does not handles the mentioned case:
>>>>
>>>> switch(type) { case 0...5: } being the equivalent of switch(type) {
>>>> case 0: case 1: case 2: case 3: case 4: case 5: }
>>>>
>>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus <
>>>> bruno.macab...@gmail.com> wrote:
>>>>
>>>>> I agree with Oriol.
>>>>> We already have the proposal pattern matching, that has a very similar
>>>>> effect.
>>>>> I think that is better to improve pattern matching proposal in order
>>>>> to be able to match using ranges (or at least check if it's good to do)
>>>>> instead of create a new proposal.
>>>>>
>>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _ 
>>>>> wrote:
>>>>>
>>>>>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>>>>>
>>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>>>>>
>>>>>> For example, the following:
>>>>>>
>>>>>> switch (value) {
>>>>>> case 0...9: break
>>>>>> case 'a'...'z': break
>>>>>> }
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> es-discuss mailing 
>>>>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> --
>>> -
>>>
>>> Isiah Meadows
>>> cont...@isiahmeadows.com
>>> www.isiahmeadows.com
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> --
>   Cheers,
>   --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Mark S. Miller]

3 < 2 < 1;  // true


On Sat, Feb 1, 2020 at 3:03 AM Naveen Chawla  wrote:

> Certain languages allow the expression 0 would be syntactically possible in JavaScript? Of course this would only
> apply for "if"/"while" statements.
>
> On Fri, 31 Jan 2020 at 22:41, Isiah Meadows 
> wrote:
>
>> Still better to discuss it there - it's highly related to your
>> suggestion. And I'm pretty sure an issue already exists related to that.
>>
>> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>>
>>> The pattern matching proposal does not handles the mentioned case:
>>>
>>> switch(type) { case 0...5: } being the equivalent of switch(type) { case
>>> 0: case 1: case 2: case 3: case 4: case 5: }
>>>
>>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus 
>>> wrote:
>>>
>>>> I agree with Oriol.
>>>> We already have the proposal pattern matching, that has a very similar
>>>> effect.
>>>> I think that is better to improve pattern matching proposal in order to
>>>> be able to match using ranges (or at least check if it's good to do)
>>>> instead of create a new proposal.
>>>>
>>>> On Fri, 31 Jan 2020 at 14:08, Oriol _ 
>>>> wrote:
>>>>
>>>>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>>>>
>>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>>>>
>>>>> For example, the following:
>>>>>
>>>>> switch (value) {
>>>>> case 0...9: break
>>>>> case 'a'...'z': break
>>>>> }
>>>>>
>>>>>
>>>>> ___
>>>>> es-discuss mailing 
>>>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> --
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


-- 
  Cheers,
  --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Naveen Chawla]

Certain languages allow the expression 0
wrote:

> Still better to discuss it there - it's highly related to your suggestion.
> And I'm pretty sure an issue already exists related to that.
>
> On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:
>
>> The pattern matching proposal does not handles the mentioned case:
>>
>> switch(type) { case 0...5: } being the equivalent of switch(type) { case
>> 0: case 1: case 2: case 3: case 4: case 5: }
>>
>> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus 
>> wrote:
>>
>>> I agree with Oriol.
>>> We already have the proposal pattern matching, that has a very similar
>>> effect.
>>> I think that is better to improve pattern matching proposal in order to
>>> be able to match using ranges (or at least check if it's good to do)
>>> instead of create a new proposal.
>>>
>>> On Fri, 31 Jan 2020 at 14:08, Oriol _ 
>>> wrote:
>>>
>>>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>>>
>>>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>>>
>>>> For example, the following:
>>>>
>>>> switch (value) {
>>>> case 0...9: break
>>>> case 'a'...'z': break
>>>> }
>>>>
>>>>
>>>> ___
>>>> es-discuss mailing 
>>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> --
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Isiah Meadows]

Still better to discuss it there - it's highly related to your suggestion.
And I'm pretty sure an issue already exists related to that.

On Fri, Jan 31, 2020 at 09:06 Sultan  wrote:

> The pattern matching proposal does not handles the mentioned case:
>
> switch(type) { case 0...5: } being the equivalent of switch(type) { case
> 0: case 1: case 2: case 3: case 4: case 5: }
>
> On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus 
> wrote:
>
>> I agree with Oriol.
>> We already have the proposal pattern matching, that has a very similar
>> effect.
>> I think that is better to improve pattern matching proposal in order to
>> be able to match using ranges (or at least check if it's good to do)
>> instead of create a new proposal.
>>
>> On Fri, 31 Jan 2020 at 14:08, Oriol _  wrote:
>>
>>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>>
>>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>>
>>> For example, the following:
>>>
>>> switch (value) {
>>> case 0...9: break
>>> case 'a'...'z': break
>>> }
>>>
>>>
>>> ___
>>> es-discuss mailing 
>>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-- 
-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Sultan]

The pattern matching proposal does not handles the mentioned case:

switch(type) { case 0...5: } being the equivalent of switch(type) { case 0:
case 1: case 2: case 3: case 4: case 5: }

On Fri, Jan 31, 2020 at 7:36 PM Bruno Macabeus 
wrote:

> I agree with Oriol.
> We already have the proposal pattern matching, that has a very similar
> effect.
> I think that is better to improve pattern matching proposal in order to be
> able to match using ranges (or at least check if it's good to do) instead
> of create a new proposal.
>
> On Fri, 31 Jan 2020 at 14:08, Oriol _  wrote:
>
>> This sounds like https://github.com/tc39/proposal-pattern-matching
>>
>> El 31/1/20 a les 10:57, Sultan ha escrit:
>>
>> For example, the following:
>>
>> switch (value) {
>> case 0...9: break
>> case 'a'...'z': break
>> }
>>
>>
>> ___
>> es-discuss mailing 
>> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Bruno Macabeus]

I agree with Oriol.
We already have the proposal pattern matching, that has a very similar
effect.
I think that is better to improve pattern matching proposal in order to be
able to match using ranges (or at least check if it's good to do) instead
of create a new proposal.

On Fri, 31 Jan 2020 at 14:08, Oriol _  wrote:

> This sounds like https://github.com/tc39/proposal-pattern-matching
>
> El 31/1/20 a les 10:57, Sultan ha escrit:
>
> For example, the following:
>
> switch (value) {
> case 0...9: break
> case 'a'...'z': break
> }
>
>
> ___
> es-discuss mailing 
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Oriol _]

This sounds like https://github.com/tc39/proposal-pattern-matching

El 31/1/20 a les 10:57, Sultan ha escrit:
For example, the following:

switch (value) {
case 0...9: break
case 'a'...'z': break
}



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: syntax for case ranges

[Felipe Nascimento de Moura]

Very interesting.

Once I wanted (and would have used a lot) something like a `switchMatch`.
It would work like this:

switchMatch(value) {
  case /\d+/: { ... }
  case /\s+/: { ... }
  case /.../: { ... }
  default: {
console.log('Didn't match any of the options');
  }
}

Of course you can have a regex like `(\d+)|(\s+)|...` but it would be more
readable and would allow situations like yours to be easily solved, read,
thought and taught.

[ ]s

*--*

*Felipe N. Moura*
Web Developer, Google Developer Expert
, Founder of
BrazilJS , Nasc  and On2
.

Website:  http://felipenmoura.com / http://nasc.io/
Twitter:@felipenmoura 
Facebook: http://fb.com/felipenmoura
LinkedIn: http://goo.gl/qGmq
-
* Changing  the  world*  is the least I expect from  myself!


On Fri, Jan 31, 2020 at 6:57 AM Sultan  wrote:

> For example, the following:
>
> switch (value) {
> case 0...9: break
> case 'a'...'z': break
> }
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

syntax for case ranges

[Sultan]

For example, the following:

switch (value) {
case 0...9: break
case 'a'...'z': break
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Cyril Auburtin]

Range literals could take form in
https://github.com/tc39/proposal-slice-notation/issues/19#issuecomment-421453934

On Thu, Jul 26, 2018 at 1:30 PM Cyril Auburtin 
wrote:

> I started wrapping the idea here https://github.com/caub/proposal-range
>
> On Wed, Jul 18, 2018 at 6:48 PM Cyril Auburtin 
> wrote:
>
>> I really like this possible new syntax for ranges:
>>
>> ```js
>> [2:9] // [2,3,4,5,6,7,8,9]
>> [1, 2, 4:7, 9] // [1, 2, 4, 5, 6, 7, 9]
>> [1:6:2] // [1, 3, 5]
>> ```
>>
>> Would someone in TC39 be up to champion this?
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Cyril Auburtin]

I started wrapping the idea here https://github.com/caub/proposal-range

On Wed, Jul 18, 2018 at 6:48 PM Cyril Auburtin 
wrote:

> I really like this possible new syntax for ranges:
>
> ```js
> [2:9] // [2,3,4,5,6,7,8,9]
> [1, 2, 4:7, 9] // [1, 2, 4, 5, 6, 7, 9]
> [1:6:2] // [1, 3, 5]
> ```
>
> Would someone in TC39 be up to champion this?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Cyril Auburtin]

I really like this possible new syntax for ranges:

```js
[2:9] // [2,3,4,5,6,7,8,9]
[1, 2, 4:7, 9] // [1, 2, 4, 5, 6, 7, 9]
[1:6:2] // [1, 3, 5]
```

Would someone in TC39 be up to champion this?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Cyril Auburtin]

s/possible benefits/possible performance benefits/
sorry

Le dim. 1 juil. 2018 à 18:13, Cyril Auburtin  a
écrit :

> Sure, good points
>
> 1) *Is it sugar?* Yes
> 2) *How much sugar?* Very few, example: `(a, b, s=1)=>Array.from({length:
> (b-a)/s+1}, (_,i)=>a+i*s)`
> 3) *Frequency of benefit?* Frequent (building arrays, functional loops)
> 4) *Expected improvement*? There are possible benefits to have a range/seq
> native function, but the main benefit is avoiding extra packages for
> something frequent
> 5) *Userland implementable?* it can definitely, in one line. The drawback
> is having to rely on an external package, to import it. leftpad now
> implemeted as String.prototype.padStart is an example case
> 6) *Implementable?* Does it present potentially difficult or intractable
> implementation challenges? No
> 7) *Consistent?* Is it consistent with existing syntactic and semantic
> practices in the languages? Yes
> 8) *Holistic?* Does it fill in some obvious logical gap in the current
> language design? Yes, `Array.from({length: n}, (_, i) =>
> doSomethingWwith(i))` or other similar non-obvious code for creating
> ranges. This new seq or range function would fill the gap between `Array`
> constructor which is not usable (because it creates sparse arrays) and
> `Array.from` or `Array.prototype.fill` which aren't practical enough for
> creating ranges
> 9) *Understandable?* Does it place an unsustainable new "cognitive burden"
> on learners and users of the language? No, rather the opposite
> 10) *Library?* Is is something that would be better provided as part of
> some kind of future standard library? I don't think so, because it's
> short, it may be a static `Array` function, or a global
> 11) *Intrusive?* Does it take over real estate that might be useful for
> future features no one has thought of yet, the obvious example being using
> special characters? No, it's a simple drop-in
> 12) *Readability?* Is it something that results in a distinct improvement
> in readability or visible semantic correctness of code? Yes, as described,
> `Array.from({length: n}, (_, i) => .. )` is not readable and practical
> enough
> 13) *Prior art?* Has this or a similar feature already been proposed, and
> if so what was the reaction, and how is your proposal different from that,
> or from a similar features existing in other languages?
> - Array.build was proposed at the time ES6 was discussed I think
> https://gist.github.com/rwaldron/11186883, it's a different approach for
> creating ranges, but already an improvement over `Array.from({length: n},
> (_, i) => .. )`
> - Array comprehensions were proposed at the time of ES6 as well, and
> rejected, reasonably in my opinion
> - languages like python has a `range` builtin, I can also think of the
> `seq` linux command, I wouldn't be opposed to a new syntax addition like
> `[1:10]` as well
>
> There were maybe proposals for it in the past, but I didn't find any so
> far, I could try to create one. Some of you seems to want generators for
> this, I'd prefer not
>
> Le dim. 1 juil. 2018 à 08:03, Bob Myers  a écrit :
>
>> It seems odd that after all these years of discussions and
>> meta-discussions about ES feature proposals, some people are still saying
>> things like:
>>
>> * there really needs to be
>> * I'd really like
>> * I'd love to have
>>
>> often without addressing a single one of the relevant questions:
>>
>> 1) *Is it sugar?* Is it "mere" syntactic sugar (which is not
>> disqualifying in and of itself), or something that requires (or benefits
>> from) being baked into the language?
>> 2) *How much sugar?* If it is wholly or partially syntactic sugar, what
>> the degree of syntactic optimization?
>> 3) *Frequency of benefit?* What is the frequency of the use case?
>> 4) *Expected improvement*? If it is something that would benefit from
>> being baked into the language, what is the degree of the benefit (eg, in
>> terms of performance)?
>> 5) *Userland implementable?* Can it be implemented in userland code? If
>> so, what's the downside of that?
>> 6) *Implementable?* Does it present potentially difficult or intractable
>> implementation challenges?
>> 7) *Consistent?* Is it consistent with existing syntactic and semantic
>> practices in the languages?
>> 8) *Holistic?* Does it fill in some obvious logical gap in the current
>> language design?
>> 9) *Understandable?* Does it place an unsustainable new "cognitive
>> burden" on learners and users of the language?
>> 10) *Library?* Is is something that would be better provided as part of
>> some kind of future standard

Re: Ranges

[Cyril Auburtin]

Sure, good points

1) *Is it sugar?* Yes
2) *How much sugar?* Very few, example: `(a, b, s=1)=>Array.from({length:
(b-a)/s+1}, (_,i)=>a+i*s)`
3) *Frequency of benefit?* Frequent (building arrays, functional loops)
4) *Expected improvement*? There are possible benefits to have a range/seq
native function, but the main benefit is avoiding extra packages for
something frequent
5) *Userland implementable?* it can definitely, in one line. The drawback
is having to rely on an external package, to import it. leftpad now
implemeted as String.prototype.padStart is an example case
6) *Implementable?* Does it present potentially difficult or intractable
implementation challenges? No
7) *Consistent?* Is it consistent with existing syntactic and semantic
practices in the languages? Yes
8) *Holistic?* Does it fill in some obvious logical gap in the current
language design? Yes, `Array.from({length: n}, (_, i) =>
doSomethingWwith(i))` or other similar non-obvious code for creating
ranges. This new seq or range function would fill the gap between `Array`
constructor which is not usable (because it creates sparse arrays) and
`Array.from` or `Array.prototype.fill` which aren't practical enough for
creating ranges
9) *Understandable?* Does it place an unsustainable new "cognitive burden"
on learners and users of the language? No, rather the opposite
10) *Library?* Is is something that would be better provided as part of
some kind of future standard library? I don't think so, because it's short,
it may be a static `Array` function, or a global
11) *Intrusive?* Does it take over real estate that might be useful for
future features no one has thought of yet, the obvious example being using
special characters? No, it's a simple drop-in
12) *Readability?* Is it something that results in a distinct improvement
in readability or visible semantic correctness of code? Yes, as described,
`Array.from({length: n}, (_, i) => .. )` is not readable and practical
enough
13) *Prior art?* Has this or a similar feature already been proposed, and
if so what was the reaction, and how is your proposal different from that,
or from a similar features existing in other languages?
- Array.build was proposed at the time ES6 was discussed I think
https://gist.github.com/rwaldron/11186883, it's a different approach for
creating ranges, but already an improvement over `Array.from({length: n},
(_, i) => .. )`
- Array comprehensions were proposed at the time of ES6 as well, and
rejected, reasonably in my opinion
- languages like python has a `range` builtin, I can also think of the
`seq` linux command, I wouldn't be opposed to a new syntax addition like
`[1:10]` as well

There were maybe proposals for it in the past, but I didn't find any so
far, I could try to create one. Some of you seems to want generators for
this, I'd prefer not

Le dim. 1 juil. 2018 à 08:03, Bob Myers  a écrit :

> It seems odd that after all these years of discussions and
> meta-discussions about ES feature proposals, some people are still saying
> things like:
>
> * there really needs to be
> * I'd really like
> * I'd love to have
>
> often without addressing a single one of the relevant questions:
>
> 1) *Is it sugar?* Is it "mere" syntactic sugar (which is not
> disqualifying in and of itself), or something that requires (or benefits
> from) being baked into the language?
> 2) *How much sugar?* If it is wholly or partially syntactic sugar, what
> the degree of syntactic optimization?
> 3) *Frequency of benefit?* What is the frequency of the use case?
> 4) *Expected improvement*? If it is something that would benefit from
> being baked into the language, what is the degree of the benefit (eg, in
> terms of performance)?
> 5) *Userland implementable?* Can it be implemented in userland code? If
> so, what's the downside of that?
> 6) *Implementable?* Does it present potentially difficult or intractable
> implementation challenges?
> 7) *Consistent?* Is it consistent with existing syntactic and semantic
> practices in the languages?
> 8) *Holistic?* Does it fill in some obvious logical gap in the current
> language design?
> 9) *Understandable?* Does it place an unsustainable new "cognitive
> burden" on learners and users of the language?
> 10) *Library?* Is is something that would be better provided as part of
> some kind of future standard library?
> 11) *Intrusive?* Does it take over real estate that might be useful for
> future features no one has thought of yet, the obvious example being using
> special characters?
> 12) *Readability?* Is it something that results in a distinct improvement
> in readability or visible semantic correctness of code?
> 13) *Prior art?* Has this or a similar feature already been proposed, and
> if so what was the reaction, and how is your proposal different from that,
> or from a si

Re: Ranges

[Bob Myers]

It seems odd that after all these years of discussions and meta-discussions
about ES feature proposals, some people are still saying things like:

* there really needs to be
* I'd really like
* I'd love to have

often without addressing a single one of the relevant questions:

1) *Is it sugar?* Is it "mere" syntactic sugar (which is not disqualifying
in and of itself), or something that requires (or benefits from) being
baked into the language?
2) *How much sugar?* If it is wholly or partially syntactic sugar, what the
degree of syntactic optimization?
3) *Frequency of benefit?* What is the frequency of the use case?
4) *Expected improvement*? If it is something that would benefit from being
baked into the language, what is the degree of the benefit (eg, in terms of
performance)?
5) *Userland implementable?* Can it be implemented in userland code? If so,
what's the downside of that?
6) *Implementable?* Does it present potentially difficult or intractable
implementation challenges?
7) *Consistent?* Is it consistent with existing syntactic and semantic
practices in the languages?
8) *Holistic?* Does it fill in some obvious logical gap in the current
language design?
9) *Understandable?* Does it place an unsustainable new "cognitive burden"
on learners and users of the language?
10) *Library?* Is is something that would be better provided as part of
some kind of future standard library?
11) *Intrusive?* Does it take over real estate that might be useful for
future features no one has thought of yet, the obvious example being using
special characters?
12) *Readability?* Is it something that results in a distinct improvement
in readability or visible semantic correctness of code?
13) *Prior art?* Has this or a similar feature already been proposed, and
if so what was the reaction, and how is your proposal different from that,
or from a similar features existing in other languages?

I'm sure there are cases where simply throwing out an informal idea and
seeing how people react is useful to get a discussions started, but most
reactions will be that the proposal does not meet one or more of the above
criteria, so proposers could save themselves and other people lots of time
in advance by explaining HOW their proposal satisfies these points, not all
of which are relevant to every proposal, but those which are.

Bob

On Sun, Jul 1, 2018 at 12:53 AM Cyril Auburtin 
wrote:

> In any case, there really needs to be a JS core function to generate
> sequences/ranges
>
> I used a lot `Array.from({length: ...`  but it's far from ideal
>
> related example:
> https://github.com/graphql/graphql.github.io/pull/456/files/1523f6dcf333eb869c96789d8f099c1a192c032a#diff-e1de70658aec08b7d432c434a64c637aords
>
> I'd like at least something like `seq(numRolls).map(() => this.rollOnce())`
>
> a `seq` global function wouldn't be less useful than a `for` keyword
>
> Le mer. 27 juin 2018 à 01:07, N. Oxer  a écrit :
>
>> I think something like [itt](https://github.com/nathan/itt) is a good
>> prototype/example for a possible iterutils module.
>>
>> On Sun, Jun 24, 2018 at 10:37 PM Isiah Meadows 
>> wrote:
>>
>>> I'd love to see ranges, but only implemented as iterables. But in
>>> reality, we really should start pushing for a proposed `iterutils` module
>>> (or similar) that has all this widely useful stuff that doesn't really have
>>> a place in the global scope, but are still generally useful. Granted, this
>>> is currently blocked on the pipeline operator proposal IIUC (not on TC39,
>>> but I've heard/read things hinting at it), but that's the main thing that
>>> really needs to happen.
>>>
>>> -
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com
>>> www.isiahmeadows.com
>>>
>>> On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <
>>> cyril.aubur...@gmail.com> wrote:
>>>
>>>> What I'd really like is something to avoid `Array.from({length: n}, (_,
>>>> i) => ..)`
>>>> It's very common to use it nowadays
>>>>
>>>> on the + side, it's a wider feature than range, the callback is more
>>>> powerful to build any kind of ranges
>>>>
>>>> but it feels quite hacky and verbose. you can make a typo on 'length',
>>>> and have to use the second callback argument.
>>>>
>>>> I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) //
>>>> [1, 3, 5, 7]` I think `Array.build` was proposed a long time ago (
>>>> array.build)
>>>>
>>>> Le mer. 14 déc. 2016 à 21:28, Alexander Jones  a écrit :
>>>>
>>>>> IMO this is quite unnecessary syntax sugar. Python has everything you
>>&

Re: Ranges

[Cyril Auburtin]

In any case, there really needs to be a JS core function to generate
sequences/ranges

I used a lot `Array.from({length: ...`  but it's far from ideal

related example:
https://github.com/graphql/graphql.github.io/pull/456/files/1523f6dcf333eb869c96789d8f099c1a192c032a#diff-e1de70658aec08b7d432c434a64c637aords

I'd like at least something like `seq(numRolls).map(() => this.rollOnce())`

a `seq` global function wouldn't be less useful than a `for` keyword



Le mer. 27 juin 2018 à 01:07, N. Oxer  a écrit :

> I think something like [itt](https://github.com/nathan/itt) is a good
> prototype/example for a possible iterutils module.
>
> On Sun, Jun 24, 2018 at 10:37 PM Isiah Meadows 
> wrote:
>
>> I'd love to see ranges, but only implemented as iterables. But in
>> reality, we really should start pushing for a proposed `iterutils` module
>> (or similar) that has all this widely useful stuff that doesn't really have
>> a place in the global scope, but are still generally useful. Granted, this
>> is currently blocked on the pipeline operator proposal IIUC (not on TC39,
>> but I've heard/read things hinting at it), but that's the main thing that
>> really needs to happen.
>>
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>> On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <
>> cyril.aubur...@gmail.com> wrote:
>>
>>> What I'd really like is something to avoid `Array.from({length: n}, (_,
>>> i) => ..)`
>>> It's very common to use it nowadays
>>>
>>> on the + side, it's a wider feature than range, the callback is more
>>> powerful to build any kind of ranges
>>>
>>> but it feels quite hacky and verbose. you can make a typo on 'length',
>>> and have to use the second callback argument.
>>>
>>> I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) //
>>> [1, 3, 5, 7]` I think `Array.build` was proposed a long time ago (
>>> array.build)
>>>
>>> Le mer. 14 déc. 2016 à 21:28, Alexander Jones  a écrit :
>>>
>>>> IMO this is quite unnecessary syntax sugar. Python has everything you
>>>> could need here without special syntax.
>>>>
>>>> On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:
>>>>
>>>>> While slightly more verbose, the previously suggested `...` syntax
>>>>> does have a superficial consistency with the spread operator. Both perform
>>>>> an expansion of sorts, which has a subtle elegance to it, IMO.
>>>>>
>>>>> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
>>>>> oao.hikaru@gmail.com> wrote:
>>>>>
>>>>> I understand.
>>>>> I hope to find a good form of literals.
>>>>>
>>>>> Is there a fact that literals are easier to optimize in the following
>>>>> cases?
>>>>>
>>>>> ```
>>>>> for (let i of [1 to 5]) { .. }
>>>>> vs
>>>>> for (let i of Array.range(1, 5)) { .. }
>>>>> ```
>>>>>
>>>>> If so, it seems that we can attract vendors' interests.
>>>>>
>>>>> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>>>>>
>>>>> I think you'd be lucky to even get to that stage.  Vendors aren't keen
>>>>> on any kind of backwards incompatibility in new specs and trying to get
>>>>> this to stage 4 with such a glaring one would be practically  impossible.
>>>>>
>>>>>
>>>>> It's not just the incompatibility either.  You also introduce an
>>>>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>>>>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to 
>>>>> developers.
>>>>>
>>>>>
>>>>> When you consider these things, it becomes clear that it's not
>>>>> practical to change the language this way for such a small benefit.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
>>>>> wrote:
>>>>>
>>>>> Oh, I understood it.
>>>>> It looks like serious problem, but it is may not actually.
>>>>> If this spec change doesn't break web, we can introduce this idea?
>>>>>
>>>>>
>>>>> ___
>>&g

Re: Ranges

[N. Oxer]

I think something like [itt](https://github.com/nathan/itt) is a good
prototype/example for a possible iterutils module.

On Sun, Jun 24, 2018 at 10:37 PM Isiah Meadows 
wrote:

> I'd love to see ranges, but only implemented as iterables. But in reality,
> we really should start pushing for a proposed `iterutils` module (or
> similar) that has all this widely useful stuff that doesn't really have a
> place in the global scope, but are still generally useful. Granted, this is
> currently blocked on the pipeline operator proposal IIUC (not on TC39, but
> I've heard/read things hinting at it), but that's the main thing that
> really needs to happen.
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
> On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin  > wrote:
>
>> What I'd really like is something to avoid `Array.from({length: n}, (_,
>> i) => ..)`
>> It's very common to use it nowadays
>>
>> on the + side, it's a wider feature than range, the callback is more
>> powerful to build any kind of ranges
>>
>> but it feels quite hacky and verbose. you can make a typo on 'length',
>> and have to use the second callback argument.
>>
>> I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) //
>> [1, 3, 5, 7]` I think `Array.build` was proposed a long time ago (
>> array.build)
>>
>> Le mer. 14 déc. 2016 à 21:28, Alexander Jones  a écrit :
>>
>>> IMO this is quite unnecessary syntax sugar. Python has everything you
>>> could need here without special syntax.
>>>
>>> On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:
>>>
>>>> While slightly more verbose, the previously suggested `...` syntax does
>>>> have a superficial consistency with the spread operator. Both perform an
>>>> expansion of sorts, which has a subtle elegance to it, IMO.
>>>>
>>>> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
>>>> oao.hikaru@gmail.com> wrote:
>>>>
>>>> I understand.
>>>> I hope to find a good form of literals.
>>>>
>>>> Is there a fact that literals are easier to optimize in the following
>>>> cases?
>>>>
>>>> ```
>>>> for (let i of [1 to 5]) { .. }
>>>> vs
>>>> for (let i of Array.range(1, 5)) { .. }
>>>> ```
>>>>
>>>> If so, it seems that we can attract vendors' interests.
>>>>
>>>> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>>>>
>>>> I think you'd be lucky to even get to that stage.  Vendors aren't keen
>>>> on any kind of backwards incompatibility in new specs and trying to get
>>>> this to stage 4 with such a glaring one would be practically  impossible.
>>>>
>>>>
>>>> It's not just the incompatibility either.  You also introduce an
>>>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>>>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>>>
>>>>
>>>> When you consider these things, it becomes clear that it's not
>>>> practical to change the language this way for such a small benefit.
>>>>
>>>>
>>>>
>>>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
>>>> wrote:
>>>>
>>>> Oh, I understood it.
>>>> It looks like serious problem, but it is may not actually.
>>>> If this spec change doesn't break web, we can introduce this idea?
>>>>
>>>>
>>>> ___
>>>>
>>>>
>>>> es-discuss mailing list
>>>>
>>>>
>>>> es-discuss@mozilla.org
>>>>
>>>>
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>>
>>>>
>>>> es-discuss mailing list
>>>>
>>>>
>>>> es-discuss@mozilla.org
>>>>
>>>>
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jeremy Martin
>>>> 661.312.3853 <(661)%20312-3853>
>>>> http://devsmash.com
>>>> @jmar777
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>>
>>>> es-discuss mailing list
>>>>
>>>> es-discuss@mozilla.org
>>>>
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Isiah Meadows]

I'd love to see ranges, but only implemented as iterables. But in reality,
we really should start pushing for a proposed `iterutils` module (or
similar) that has all this widely useful stuff that doesn't really have a
place in the global scope, but are still generally useful. Granted, this is
currently blocked on the pipeline operator proposal IIUC (not on TC39, but
I've heard/read things hinting at it), but that's the main thing that
really needs to happen.

-

Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin 
wrote:

> What I'd really like is something to avoid `Array.from({length: n}, (_, i)
> => ..)`
> It's very common to use it nowadays
>
> on the + side, it's a wider feature than range, the callback is more
> powerful to build any kind of ranges
>
> but it feels quite hacky and verbose. you can make a typo on 'length', and
> have to use the second callback argument.
>
> I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) //
> [1, 3, 5, 7]` I think `Array.build` was proposed a long time ago (
> array.build)
>
> Le mer. 14 déc. 2016 à 21:28, Alexander Jones  a écrit :
>
>> IMO this is quite unnecessary syntax sugar. Python has everything you
>> could need here without special syntax.
>>
>> On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:
>>
>>> While slightly more verbose, the previously suggested `...` syntax does
>>> have a superficial consistency with the spread operator. Both perform an
>>> expansion of sorts, which has a subtle elegance to it, IMO.
>>>
>>> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
>>> oao.hikaru@gmail.com> wrote:
>>>
>>> I understand.
>>> I hope to find a good form of literals.
>>>
>>> Is there a fact that literals are easier to optimize in the following
>>> cases?
>>>
>>> ```
>>> for (let i of [1 to 5]) { .. }
>>> vs
>>> for (let i of Array.range(1, 5)) { .. }
>>> ```
>>>
>>> If so, it seems that we can attract vendors' interests.
>>>
>>> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>>>
>>> I think you'd be lucky to even get to that stage.  Vendors aren't keen
>>> on any kind of backwards incompatibility in new specs and trying to get
>>> this to stage 4 with such a glaring one would be practically  impossible.
>>>
>>>
>>> It's not just the incompatibility either.  You also introduce an
>>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>>
>>>
>>> When you consider these things, it becomes clear that it's not practical
>>> to change the language this way for such a small benefit.
>>>
>>>
>>>
>>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
>>> wrote:
>>>
>>> Oh, I understood it.
>>> It looks like serious problem, but it is may not actually.
>>> If this spec change doesn't break web, we can introduce this idea?
>>>
>>>
>>> ___
>>>
>>>
>>> es-discuss mailing list
>>>
>>>
>>> es-discuss@mozilla.org
>>>
>>>
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>>
>>>
>>> es-discuss mailing list
>>>
>>>
>>> es-discuss@mozilla.org
>>>
>>>
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>>
>>>
>>>
>>>
>>> ___
>>>
>>> es-discuss mailing list
>>>
>>> es-discuss@mozilla.org
>>>
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Jerry Schulteis]

 At least Array.build isn't "taken" by MooTools.

For the particular example, I prefer something like [...take(4, oddNumbers())], 
but in some cases Array.build would provide better clarity.

On Sunday, June 24, 2018, 10:34:58 AM CDT, Cyril Auburtin 
 wrote:  
 
 What I'd really like is something to avoid `Array.from({length: n}, (_, i) => 
..)`It's very common to use it nowadays
on the + side, it's a wider feature than range, the callback is more powerful 
to build any kind of ranges
but it feels quite hacky and verbose. you can make a typo on 'length', and have 
to use the second callback argument.

I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) // [1, 3, 
5, 7]` I think `Array.build` was proposed a long time ago (array.build)

  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Cyril Auburtin]

What I'd really like is something to avoid `Array.from({length: n}, (_, i)
=> ..)`
It's very common to use it nowadays

on the + side, it's a wider feature than range, the callback is more
powerful to build any kind of ranges

but it feels quite hacky and verbose. you can make a typo on 'length', and
have to use the second callback argument.

I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) // [1,
3, 5, 7]` I think `Array.build` was proposed a long time ago (array.build)

Le mer. 14 déc. 2016 à 21:28, Alexander Jones  a écrit :

> IMO this is quite unnecessary syntax sugar. Python has everything you
> could need here without special syntax.
>
> On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:
>
>> While slightly more verbose, the previously suggested `...` syntax does
>> have a superficial consistency with the spread operator. Both perform an
>> expansion of sorts, which has a subtle elegance to it, IMO.
>>
>> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
>> oao.hikaru@gmail.com> wrote:
>>
>> I understand.
>> I hope to find a good form of literals.
>>
>> Is there a fact that literals are easier to optimize in the following
>> cases?
>>
>> ```
>> for (let i of [1 to 5]) { .. }
>> vs
>> for (let i of Array.range(1, 5)) { .. }
>> ```
>>
>> If so, it seems that we can attract vendors' interests.
>>
>> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>>
>> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
>> any kind of backwards incompatibility in new specs and trying to get this
>> to stage 4 with such a glaring one would be practically  impossible.
>>
>>
>> It's not just the incompatibility either.  You also introduce an
>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>
>>
>> When you consider these things, it becomes clear that it's not practical
>> to change the language this way for such a small benefit.
>>
>>
>>
>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
>> wrote:
>>
>> Oh, I understood it.
>> It looks like serious problem, but it is may not actually.
>> If this spec change doesn't break web, we can introduce this idea?
>>
>>
>> ___
>>
>>
>> es-discuss mailing list
>>
>>
>> es-discuss@mozilla.org
>>
>>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>>
>>
>> es-discuss mailing list
>>
>>
>> es-discuss@mozilla.org
>>
>>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>>
>>
>> --
>> Jeremy Martin
>> 661.312.3853
>> http://devsmash.com
>> @jmar777
>>
>>
>>
>>
>> ___
>>
>> es-discuss mailing list
>>
>> es-discuss@mozilla.org
>>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Alexander Jones]

IMO this is quite unnecessary syntax sugar. Python has everything you could
need here without special syntax.

On Wed, 14 Dec 2016 at 16:55, Jeremy Martin  wrote:

> While slightly more verbose, the previously suggested `...` syntax does
> have a superficial consistency with the spread operator. Both perform an
> expansion of sorts, which has a subtle elegance to it, IMO.
>
> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
> oao.hikaru@gmail.com> wrote:
>
> I understand.
> I hope to find a good form of literals.
>
> Is there a fact that literals are easier to optimize in the following
> cases?
>
> ```
> for (let i of [1 to 5]) { .. }
> vs
> for (let i of Array.range(1, 5)) { .. }
> ```
>
> If so, it seems that we can attract vendors' interests.
>
> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>
> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
> any kind of backwards incompatibility in new specs and trying to get this
> to stage 4 with such a glaring one would be practically  impossible.
>
>
> It's not just the incompatibility either.  You also introduce an
> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>
>
> When you consider these things, it becomes clear that it's not practical
> to change the language this way for such a small benefit.
>
>
>
> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
> wrote:
>
> Oh, I understood it.
> It looks like serious problem, but it is may not actually.
> If this spec change doesn't break web, we can introduce this idea?
>
>
> ___
>
>
> es-discuss mailing list
>
>
> es-discuss@mozilla.org
>
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
>
>
> ___
>
>
> es-discuss mailing list
>
>
> es-discuss@mozilla.org
>
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
>
>
>
> ___
>
> es-discuss mailing list
>
> es-discuss@mozilla.org
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Jeremy Martin]

While slightly more verbose, the previously suggested `...` syntax does
have a superficial consistency with the spread operator. Both perform an
expansion of sorts, which has a subtle elegance to it, IMO.

On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima 
wrote:

> I understand.
> I hope to find a good form of literals.
>
> Is there a fact that literals are easier to optimize in the following
> cases?
>
> ```
> for (let i of [1 to 5]) { .. }
> vs
> for (let i of Array.range(1, 5)) { .. }
> ```
>
> If so, it seems that we can attract vendors' interests.
>
> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw :
>
>> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
>> any kind of backwards incompatibility in new specs and trying to get this
>> to stage 4 with such a glaring one would be practically  impossible.
>>
>> It's not just the incompatibility either.  You also introduce an
>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>
>> When you consider these things, it becomes clear that it's not practical
>> to change the language this way for such a small benefit.
>>
>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
>> wrote:
>>
>>> Oh, I understood it.
>>> It looks like serious problem, but it is may not actually.
>>> If this spec change doesn't break web, we can introduce this idea?
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Hikaru Nakashima]

I understand.
I hope to find a good form of literals.

Is there a fact that literals are easier to optimize in the following cases?

```
for (let i of [1 to 5]) { .. }
vs
for (let i of Array.range(1, 5)) { .. }
```

If so, it seems that we can attract vendors' interests.

2016-12-14 17:29 GMT+09:00 Andy Earnshaw :

> I think you'd be lucky to even get to that stage.  Vendors aren't keen on
> any kind of backwards incompatibility in new specs and trying to get this
> to stage 4 with such a glaring one would be practically  impossible.
>
> It's not just the incompatibility either.  You also introduce an
> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>
> When you consider these things, it becomes clear that it's not practical
> to change the language this way for such a small benefit.
>
> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
> wrote:
>
>> Oh, I understood it.
>> It looks like serious problem, but it is may not actually.
>> If this spec change doesn't break web, we can introduce this idea?
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Andy Earnshaw]

I think you'd be lucky to even get to that stage.  Vendors aren't keen on
any kind of backwards incompatibility in new specs and trying to get this
to stage 4 with such a glaring one would be practically  impossible.

It's not just the incompatibility either.  You also introduce an
inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.

When you consider these things, it becomes clear that it's not practical to
change the language this way for such a small benefit.

On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, 
wrote:

> Oh, I understood it.
> It looks like serious problem, but it is may not actually.
> If this spec change doesn't break web, we can introduce this idea?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Hikaru Nakashima]

Oh, I understood it.
It looks like serious problem, but it is may not actually.
If this spec change doesn't break web, we can introduce this idea?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Tab Atkins Jr.]

On Tue, Dec 13, 2016 at 3:07 AM, Hikaru Nakashima
 wrote:
> My idia is as follows:
>
> ```
> [1..5]  //-> [1,2,3,4,5]
>
> (1..5)   //-> iterate 1, 2, 3, 4, 5
>
>
> [1..Infinity]  // -> TypeError because n > 2**32-1
>
> (1..Infinity)  // -> valid iterator
> ```

As Andy just explained in the previous message, that doesn't work.  In
particular, `[1..end]` is equivalent to `[(1).end]`, which is a
perfectly valid expression that creates a length-1 array containing
the value of the "end" property from a Number wrapper auto-constructed
around 1.  (Which happens to be undefined, unless you do shenanigans.)

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Hikaru Nakashima]

My idia is as follows:

```
[1..5]  //-> [1,2,3,4,5]

(1..5)   //-> iterate 1, 2, 3, 4, 5


[1..Infinity]  // -> TypeError because n > 2**32-1

(1..Infinity)  // -> valid iterator
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Andy Earnshaw]

On Thu, 3 Nov 2016 at 22:11 Zach Lym  wrote:

> With regard to syntax, Rust's is the best that I've seen: '0 ... 10'
> inclusive and  '1 .. 9' exclusive.
>

I love Rust's syntax too, but unfortunately 1.. is already valid
ES syntax:

1..Infinity
//-> undefined

Number.prototype.foo = 'bar'
1..foo
//-> 'bar'

You'd have to enforce the spaces around the operator, which would be weird
IMO.  `...` would be ok though.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Jordan Harband]

lol thanks, good call. too much habit typing "const" :-p s/const/let there

On Fri, Nov 4, 2016 at 10:39 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> FWIW: got bitten from same thing too ... the fact `for(const x of ...)`
> works would always mislead me to think a `for(const i; ... i++)` would too,
> even if it's completely different meaning/issue/matter.
>
> Oh well
>
> On Fri, Nov 4, 2016 at 5:34 PM, Mathias Bynens  wrote:
>
>> On Fri, Nov 4, 2016 at 6:24 PM, Jordan Harband  wrote:
>> > Here you go:
>> >
>> > 1) `function* range(start, end) { for (const i = +start; i < end; ++i) {
>> > yield i; } }`
>>
>> For future reference: `++i` throws when `i` is a `const` binding. The
>> intended example uses `let` instead.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Andrea Giammarchi]

FWIW: got bitten from same thing too ... the fact `for(const x of ...)`
works would always mislead me to think a `for(const i; ... i++)` would too,
even if it's completely different meaning/issue/matter.

Oh well

On Fri, Nov 4, 2016 at 5:34 PM, Mathias Bynens  wrote:

> On Fri, Nov 4, 2016 at 6:24 PM, Jordan Harband  wrote:
> > Here you go:
> >
> > 1) `function* range(start, end) { for (const i = +start; i < end; ++i) {
> > yield i; } }`
>
> For future reference: `++i` throws when `i` is a `const` binding. The
> intended example uses `let` instead.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Mathias Bynens]

On Fri, Nov 4, 2016 at 6:24 PM, Jordan Harband  wrote:
> Here you go:
>
> 1) `function* range(start, end) { for (const i = +start; i < end; ++i) {
> yield i; } }`

For future reference: `++i` throws when `i` is a `const` binding. The
intended example uses `let` instead.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Jordan Harband]

Here you go:

1) `function* range(start, end) { for (const i = +start; i < end; ++i) {
yield i; } }`
2) `function range(start, end) { return Array.from({ length: start - end },
(_, i) => start + i); }`

On Fri, Nov 4, 2016 at 7:42 AM, Michael J. Ryan <track...@gmail.com> wrote:

> Your right... The more I think about it...
>
> Number.range(from=0, to=Number. MAX_SAFE_INTEGER)
>
> Is probably best, as a signature, then using .map(...) If you want a
> string representation...
>
> For that matter, wouldn't mind seeing more of the array utility methods,
> like map, added to strings, iterating through each character, same as
> .split('').map, but that's another discussion.
>
> On Nov 4, 2016 3:11 AM, "Alexander Jones" <a...@weej.com> wrote:
>
> +1000
>
> Classic feature creep with basically zero application.
>
>
> On Thursday, 3 November 2016, Isiah Meadows <isiahmead...@gmail.com>
> wrote:
>
>> Could we just *not* have a `String.range`?
>>
>> 1. Needing a list of alphabetically sorted characters is a bit niche,
>> even in the Latin alphabet.
>> 2. It's ambiguous whether it should include symbols or not. (think:
>> `String.range("A", "z")`)
>> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
>> "π")`?
>>
>> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com>
>> wrote:
>>
>>> Even more interestingly what would `String.range("","zzz")` produce.
>>> From what code point is the range started? Will this throw? Is the empty
>>> string included in the iterator?
>>> 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:
>>>
>>>> Actually, after giving it some more thought for that case there is just
>>>> that one possibility that makes sense.
>>>>
>>>> However, there are more ambiguous cases such as `String.range("AAA",
>>>> "ZZZ")` (should all letters increase at once or should the rightmost letter
>>>> be incremented first)
>>>>
>>>> Also, how would range handle the arguments in inverted order? Should
>>>> there be a decreasing range or should it terminate with no elements in the
>>>> iterator?
>>>> 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
>>>>
>>>>> About the code points: `String.range` should also handle surrogate
>>>>> pairs, similar to for..of does it.
>>>>> About `String.range("A", "zzz")`: Do any other possibilities even make
>>>>> sense?
>>>>>
>>>>> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
>>>>> > For `String.range` what would the expected result of
>>>>> > `String.range('A','zzz')` be?
>>>>> >
>>>>> > Is an exhaustive pattern expected?
>>>>> >
>>>>> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
>>>>> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
>>>>> >
>>>>> > > If there's a Number.range, if suggest a corresponding String.range
>>>>> for
>>>>> > > character ranges...  Agreed on it being a utility function over me
>>>>> syntax.
>>>>> > >
>>>>> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
>>>>> wrote:
>>>>> > >
>>>>> > > If string ranges are based on character codes, it will (for the
>>>>> Latin
>>>>> > > alphabet, at least, not necessarily for other languages).
>>>>> > >
>>>>> > > I would prefer a function over syntax, though, since it would be
>>>>> more
>>>>> > > easily adopted (polyfill > syntax), and it would fit more
>>>>> idiomatically
>>>>> > > with the rest of the language (which also uses functions for most
>>>>> > > utilities).
>>>>> > >
>>>>> > > Maybe a `Number.range` would work?
>>>>> > >
>>>>> > > ```js
>>>>> > > Number.range = function *range(start, end=undefined, step=1) {
>>>>> > >   if (end === undefined) [start, end] = [0, start];
>>>>> > >   if (end === undefined) end = Infinity;
>>>>> > >   for (let i = 0; i < end; i += 

Re: Ranges

[Michael J. Ryan]

Your right... The more I think about it...

Number.range(from=0, to=Number. MAX_SAFE_INTEGER)

Is probably best, as a signature, then using .map(...) If you want a string
representation...

For that matter, wouldn't mind seeing more of the array utility methods,
like map, added to strings, iterating through each character, same as
.split('').map, but that's another discussion.

On Nov 4, 2016 3:11 AM, "Alexander Jones" <a...@weej.com> wrote:

+1000

Classic feature creep with basically zero application.


On Thursday, 3 November 2016, Isiah Meadows <isiahmead...@gmail.com> wrote:

> Could we just *not* have a `String.range`?
>
> 1. Needing a list of alphabetically sorted characters is a bit niche, even
> in the Latin alphabet.
> 2. It's ambiguous whether it should include symbols or not. (think:
> `String.range("A", "z")`)
> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> "π")`?
>
> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com>
> wrote:
>
>> Even more interestingly what would `String.range("","zzz")` produce. From
>> what code point is the range started? Will this throw? Is the empty string
>> included in the iterator?
>> 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:
>>
>>> Actually, after giving it some more thought for that case there is just
>>> that one possibility that makes sense.
>>>
>>> However, there are more ambiguous cases such as `String.range("AAA",
>>> "ZZZ")` (should all letters increase at once or should the rightmost letter
>>> be incremented first)
>>>
>>> Also, how would range handle the arguments in inverted order? Should
>>> there be a decreasing range or should it terminate with no elements in the
>>> iterator?
>>> 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
>>>
>>>> About the code points: `String.range` should also handle surrogate
>>>> pairs, similar to for..of does it.
>>>> About `String.range("A", "zzz")`: Do any other possibilities even make
>>>> sense?
>>>>
>>>> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
>>>> > For `String.range` what would the expected result of
>>>> > `String.range('A','zzz')` be?
>>>> >
>>>> > Is an exhaustive pattern expected?
>>>> >
>>>> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
>>>> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
>>>> >
>>>> > > If there's a Number.range, if suggest a corresponding String.range
>>>> for
>>>> > > character ranges...  Agreed on it being a utility function over me
>>>> syntax.
>>>> > >
>>>> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
>>>> wrote:
>>>> > >
>>>> > > If string ranges are based on character codes, it will (for the
>>>> Latin
>>>> > > alphabet, at least, not necessarily for other languages).
>>>> > >
>>>> > > I would prefer a function over syntax, though, since it would be
>>>> more
>>>> > > easily adopted (polyfill > syntax), and it would fit more
>>>> idiomatically
>>>> > > with the rest of the language (which also uses functions for most
>>>> > > utilities).
>>>> > >
>>>> > > Maybe a `Number.range` would work?
>>>> > >
>>>> > > ```js
>>>> > > Number.range = function *range(start, end=undefined, step=1) {
>>>> > >   if (end === undefined) [start, end] = [0, start];
>>>> > >   if (end === undefined) end = Infinity;
>>>> > >   for (let i = 0; i < end; i += step) {
>>>> > > yield i;
>>>> > >   }
>>>> > > };
>>>> > > ```
>>>> > >
>>>> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
>>>> > >
>>>> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't
>>>> just
>>>> > > return a generator
>>>> > > or at least something that extends a generator, though. I wonder if
>>>

Re: Ranges

[Alexander Jones]

+1000

Classic feature creep with basically zero application.

On Thursday, 3 November 2016, Isiah Meadows <isiahmead...@gmail.com> wrote:

> Could we just *not* have a `String.range`?
>
> 1. Needing a list of alphabetically sorted characters is a bit niche, even
> in the Latin alphabet.
> 2. It's ambiguous whether it should include symbols or not. (think:
> `String.range("A", "z")`)
> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> "π")`?
>
> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com
> <javascript:_e(%7B%7D,'cvml','viktor.kronv...@gmail.com');>> wrote:
>
>> Even more interestingly what would `String.range("","zzz")` produce. From
>> what code point is the range started? Will this throw? Is the empty string
>> included in the iterator?
>> 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','viktor.kronv...@gmail.com');>>:
>>
>>> Actually, after giving it some more thought for that case there is just
>>> that one possibility that makes sense.
>>>
>>> However, there are more ambiguous cases such as `String.range("AAA",
>>> "ZZZ")` (should all letters increase at once or should the rightmost letter
>>> be incremented first)
>>>
>>> Also, how would range handle the arguments in inverted order? Should
>>> there be a decreasing range or should it terminate with no elements in the
>>> iterator?
>>> 2016年11月3日(木) 21:05 kdex <k...@kdex.de
>>> <javascript:_e(%7B%7D,'cvml','k...@kdex.de');>>:
>>>
>>>> About the code points: `String.range` should also handle surrogate
>>>> pairs, similar to for..of does it.
>>>> About `String.range("A", "zzz")`: Do any other possibilities even make
>>>> sense?
>>>>
>>>> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
>>>> > For `String.range` what would the expected result of
>>>> > `String.range('A','zzz')` be?
>>>> >
>>>> > Is an exhaustive pattern expected?
>>>> >
>>>> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
>>>> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','track...@gmail.com');>>:
>>>> >
>>>> > > If there's a Number.range, if suggest a corresponding String.range
>>>> for
>>>> > > character ranges...  Agreed on it being a utility function over me
>>>> syntax.
>>>> > >
>>>> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','isiahmead...@gmail.com');>> wrote:
>>>> > >
>>>> > > If string ranges are based on character codes, it will (for the
>>>> Latin
>>>> > > alphabet, at least, not necessarily for other languages).
>>>> > >
>>>> > > I would prefer a function over syntax, though, since it would be
>>>> more
>>>> > > easily adopted (polyfill > syntax), and it would fit more
>>>> idiomatically
>>>> > > with the rest of the language (which also uses functions for most
>>>> > > utilities).
>>>> > >
>>>> > > Maybe a `Number.range` would work?
>>>> > >
>>>> > > ```js
>>>> > > Number.range = function *range(start, end=undefined, step=1) {
>>>> > >   if (end === undefined) [start, end] = [0, start];
>>>> > >   if (end === undefined) end = Infinity;
>>>> > >   for (let i = 0; i < end; i += step) {
>>>> > > yield i;
>>>> > >   }
>>>> > > };
>>>> > > ```
>>>> > >
>>>> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de
>>>> <javascript:_e(%7B%7D,'cvml','k...@kdex.de');>> wrote:
>>>> > >
>>>> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't
>>>> just
>>>> > > return a generator
>>>> > > or at least something that extends a generator, though. I wonder if
>>>> it's
>>>> > > viable to implement
>>>> > > something akin to `.length` on ranges, which could be natural
>>>> numbers or

Re: Ranges

[Zach Lym]

With regard to syntax, Rust's is the best that I've seen: '0 ... 10'
inclusive and  '1 .. 9' exclusive.

> for ( i of [1..10] )  { ... }

Why do we need to clutter the syntax with brackets?

Strings are something that's needed, I've been tinkering with a LINQ syntax
for IndexedDB and a Range type would make it easier to take advantage of
indexing.

However, there is not right answer here: is "10A" > "001B"?  What if I'm
storing DNS labels, where `mail.example.com` < `*.example.com`?

I think there should be a sane default (perhaps with syntactic sugar to
specify region encoding and Unicode normalization) but just people to
create extend a Range object so they can build their own semantics.

Thank you,
-Zach Lym

On Thu, Nov 3, 2016 at 2:26 PM, kdex <k...@kdex.de> wrote:

> I don't think we should give the Latin alphabet special treatment. This is
> solely about Unicode codepoints.
>
> I'd expect…
>
> - `String.range("AAA", "ZZZ")` to generate ["AAA", "AAB", …,
> "ABA", … "ZZZ"].
> - `String.range("", "zzz")` to either throw or be equivalent to
> `String.range("\u", "zzz")`.
> - `String.range("z", "A")` to either throw or wrap around at
> "\u{ff}" and therefore include
> all codepoints.
> - `String.range("A", "z")` to include symbols, too. If you only
> need letters in latin-1, you should
> either write a custom latin-1 generator or skip these
> values with a RegExp when iterating
> over them. Or just use two ranges, one for A-Z and one for
> a-z.
> - `String.range("A", "π")` to include all characters from "\u0065"
> (A) to "\u03c0" (π).
> - `String.range("", "")` to generate ["", "", "", ""]
> (surrogate pairs being respected)
>
> For more complicated cases, it might make more sense to make users pass a
> function to `String.range`
> for fine-grained control, or maybe just make users create their own
> generators.
>
> On Thursday, November 3, 2016 8:54:16 PM CET you wrote:
> > Could we just *not* have a `String.range`?
> >
> > 1. Needing a list of alphabetically sorted characters is a bit niche,
> even
> > in the Latin alphabet.
> > 2. It's ambiguous whether it should include symbols or not. (think:
> > `String.range("A", "z")`)
> > 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> > "π")`?
> >
> > On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com>
> > wrote:
> >
> > > Even more interestingly what would `String.range("","zzz")` produce.
> From
> > > what code point is the range started? Will this throw? Is the empty
> string
> > > included in the iterator?
> > > 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:
> > >
> > > Actually, after giving it some more thought for that case there is just
> > > that one possibility that makes sense.
> > >
> > > However, there are more ambiguous cases such as `String.range("AAA",
> > > "ZZZ")` (should all letters increase at once or should the rightmost
> letter
> > > be incremented first)
> > >
> > > Also, how would range handle the arguments in inverted order? Should
> there
> > > be a decreasing range or should it terminate with no elements in the
> > > iterator?
> > > 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
> > >
> > > About the code points: `String.range` should also handle surrogate
> pairs,
> > > similar to for..of does it.
> > > About `String.range("A", "zzz")`: Do any other possibilities even make
> > > sense?
> > >
> > > On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > > > For `String.range` what would the expected result of
> > > > `String.range('A','zzz')` be?
> > > >
> > > > Is an exhaustive pattern expected?
> > > >
> > > > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > > > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> > > >
> > > > > If there's a Number.range, if suggest a corresponding String.range
> for
> > > > > character ranges...  Agreed on it being a utility function over me
> > > syntax.
> > > > >
&

Re: Ranges

[kdex]

I don't think we should give the Latin alphabet special treatment. This is 
solely about Unicode codepoints.

I'd expect…

- `String.range("AAA", "ZZZ")` to generate ["AAA", "AAB", …, "ABA", … 
"ZZZ"].
- `String.range("", "zzz")` to either throw or be equivalent to 
`String.range("\u", "zzz")`.
- `String.range("z", "A")` to either throw or wrap around at 
"\u{ff}" and therefore include
all codepoints.
- `String.range("A", "z")` to include symbols, too. If you only need 
letters in latin-1, you should
    either write a custom latin-1 generator or skip these values 
with a RegExp when iterating
over them. Or just use two ranges, one for A-Z and one for a-z.
- `String.range("A", "π")` to include all characters from "\u0065" (A) 
to "\u03c0" (π).
- `String.range("", "")` to generate ["", "", "", ""] (surrogate 
pairs being respected)

For more complicated cases, it might make more sense to make users pass a 
function to `String.range`
for fine-grained control, or maybe just make users create their own generators.

On Thursday, November 3, 2016 8:54:16 PM CET you wrote:
> Could we just *not* have a `String.range`?
> 
> 1. Needing a list of alphabetically sorted characters is a bit niche, even
> in the Latin alphabet.
> 2. It's ambiguous whether it should include symbols or not. (think:
> `String.range("A", "z")`)
> 3. If it's Unicode-aware, how should it act with, say, `String.range("A",
> "π")`?
> 
> On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com>
> wrote:
> 
> > Even more interestingly what would `String.range("","zzz")` produce. From
> > what code point is the range started? Will this throw? Is the empty string
> > included in the iterator?
> > 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:
> >
> > Actually, after giving it some more thought for that case there is just
> > that one possibility that makes sense.
> >
> > However, there are more ambiguous cases such as `String.range("AAA",
> > "ZZZ")` (should all letters increase at once or should the rightmost letter
> > be incremented first)
> >
> > Also, how would range handle the arguments in inverted order? Should there
> > be a decreasing range or should it terminate with no elements in the
> > iterator?
> > 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
> >
> > About the code points: `String.range` should also handle surrogate pairs,
> > similar to for..of does it.
> > About `String.range("A", "zzz")`: Do any other possibilities even make
> > sense?
> >
> > On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > > For `String.range` what would the expected result of
> > > `String.range('A','zzz')` be?
> > >
> > > Is an exhaustive pattern expected?
> > >
> > > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> > >
> > > > If there's a Number.range, if suggest a corresponding String.range for
> > > > character ranges...  Agreed on it being a utility function over me
> > syntax.
> > > >
> > > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
> > wrote:
> > > >
> > > > If string ranges are based on character codes, it will (for the Latin
> > > > alphabet, at least, not necessarily for other languages).
> > > >
> > > > I would prefer a function over syntax, though, since it would be more
> > > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > > with the rest of the language (which also uses functions for most
> > > > utilities).
> > > >
> > > > Maybe a `Number.range` would work?
> > > >
> > > > ```js
> > > > Number.range = function *range(start, end=undefined, step=1) {
> > > >   if (end === undefined) [start, end] = [0, start];
> > > >   if (end === undefined) end = Infinity;
> > > >   for (let i = 0; i < end; i += step) {
> > > > yield i;
> > > >   }
> > > > };
> > > > ```
> > > >
> > > > On Thu, Nov 3, 2016, 12:56 kdex <k...

Re: Ranges

[Isiah Meadows]

Could we just *not* have a `String.range`?

1. Needing a list of alphabetically sorted characters is a bit niche, even
in the Latin alphabet.
2. It's ambiguous whether it should include symbols or not. (think:
`String.range("A", "z")`)
3. If it's Unicode-aware, how should it act with, say, `String.range("A",
"π")`?

On Thu, Nov 3, 2016, 16:21 Viktor Kronvall <viktor.kronv...@gmail.com>
wrote:

> Even more interestingly what would `String.range("","zzz")` produce. From
> what code point is the range started? Will this throw? Is the empty string
> included in the iterator?
> 2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:
>
> Actually, after giving it some more thought for that case there is just
> that one possibility that makes sense.
>
> However, there are more ambiguous cases such as `String.range("AAA",
> "ZZZ")` (should all letters increase at once or should the rightmost letter
> be incremented first)
>
> Also, how would range handle the arguments in inverted order? Should there
> be a decreasing range or should it terminate with no elements in the
> iterator?
> 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
>
> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >

Re: Ranges

[Viktor Kronvall]

Even more interestingly what would `String.range("","zzz")` produce. From
what code point is the range started? Will this throw? Is the empty string
included in the iterator?
2016年11月3日(木) 21:18 Viktor Kronvall <viktor.kronv...@gmail.com>:

> Actually, after giving it some more thought for that case there is just
> that one possibility that makes sense.
>
> However, there are more ambiguous cases such as `String.range("AAA",
> "ZZZ")` (should all letters increase at once or should the rightmost letter
> be incremented first)
>
> Also, how would range handle the arguments in inverted order? Should there
> be a decreasing range or should it terminate with no elements in the
> iterator?
> 2016年11月3日(木) 21:05 kdex <k...@kdex.de>:
>
> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > es-discuss mailing list
> > > > > es-discuss@mozilla.org
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > >
> > > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Viktor Kronvall]

Actually, after giving it some more thought for that case there is just
that one possibility that makes sense.

However, there are more ambiguous cases such as `String.range("AAA",
"ZZZ")` (should all letters increase at once or should the rightmost letter
be incremented first)

Also, how would range handle the arguments in inverted order? Should there
be a decreasing range or should it terminate with no elements in the
iterator?
2016年11月3日(木) 21:05 kdex <k...@kdex.de>:

> About the code points: `String.range` should also handle surrogate pairs,
> similar to for..of does it.
> About `String.range("A", "zzz")`: Do any other possibilities even make
> sense?
>
> On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> > For `String.range` what would the expected result of
> > `String.range('A','zzz')` be?
> >
> > Is an exhaustive pattern expected?
> >
> > `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> > 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> >
> > > If there's a Number.range, if suggest a corresponding String.range for
> > > character ranges...  Agreed on it being a utility function over me
> syntax.
> > >
> > > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com>
> wrote:
> > >
> > > If string ranges are based on character codes, it will (for the Latin
> > > alphabet, at least, not necessarily for other languages).
> > >
> > > I would prefer a function over syntax, though, since it would be more
> > > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > > with the rest of the language (which also uses functions for most
> > > utilities).
> > >
> > > Maybe a `Number.range` would work?
> > >
> > > ```js
> > > Number.range = function *range(start, end=undefined, step=1) {
> > >   if (end === undefined) [start, end] = [0, start];
> > >   if (end === undefined) end = Infinity;
> > >   for (let i = 0; i < end; i += step) {
> > > yield i;
> > >   }
> > > };
> > > ```
> > >
> > > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
> > >
> > > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > > return a generator
> > > or at least something that extends a generator, though. I wonder if
> it's
> > > viable to implement
> > > something akin to `.length` on ranges, which could be natural numbers
> or
> > > `Infinity`.
> > >
> > > As for numbers, I don't see any issues. One issue that came up in the
> > > original thread was
> > > that string ranges may need a better definition, as ["A".."C"] might
> not
> > > necessarily transpile
> > > to be a generator that yields "A", "B" and "C".
> > >
> > > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > > I'll note, just for clarity, that Scala's `1 to 10` is technically
> just a
> > > > normal method call equivalent to `(1).to(10)`, with optional
> parentheses
> > > > removed.
> > > >
> > > > Also, I'd prefer this to be a generator instead, so infinite ranges
> are
> > > > also possible, and so it doesn't have to be eager.
> > > >
> > > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <
> oao.hikaru@gmail.com>
> > > > wrote:
> > > >
> > > > > How about this
> > > > >
> > > > > ```
> > > > > for ( i of Array.range(1, 10) ) { ... }
> > > > > // OR
> > > > > for ( i of [1..10] )  { ... }
> > > > > ```
> > > > >
> > > > >
> > > > > ___
> > > > > es-discuss mailing list
> > > > > es-discuss@mozilla.org
> > > > > https://mail.mozilla.org/listinfo/es-discuss
> > > > >
> > > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[kdex]

About the code points: `String.range` should also handle surrogate pairs, 
similar to for..of does it.
About `String.range("A", "zzz")`: Do any other possibilities even make sense?

On Thursday, November 3, 2016 6:47:04 PM CET Viktor Kronvall wrote:
> For `String.range` what would the expected result of
> `String.range('A','zzz')` be?
> 
> Is an exhaustive pattern expected?
> 
> `['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
> 2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:
> 
> > If there's a Number.range, if suggest a corresponding String.range for
> > character ranges...  Agreed on it being a utility function over me syntax.
> >
> > On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:
> >
> > If string ranges are based on character codes, it will (for the Latin
> > alphabet, at least, not necessarily for other languages).
> >
> > I would prefer a function over syntax, though, since it would be more
> > easily adopted (polyfill > syntax), and it would fit more idiomatically
> > with the rest of the language (which also uses functions for most
> > utilities).
> >
> > Maybe a `Number.range` would work?
> >
> > ```js
> > Number.range = function *range(start, end=undefined, step=1) {
> >   if (end === undefined) [start, end] = [0, start];
> >   if (end === undefined) end = Infinity;
> >   for (let i = 0; i < end; i += step) {
> > yield i;
> >   }
> > };
> > ```
> >
> > On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
> >
> > Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> > return a generator
> > or at least something that extends a generator, though. I wonder if it's
> > viable to implement
> > something akin to `.length` on ranges, which could be natural numbers or
> > `Infinity`.
> >
> > As for numbers, I don't see any issues. One issue that came up in the
> > original thread was
> > that string ranges may need a better definition, as ["A".."C"] might not
> > necessarily transpile
> > to be a generator that yields "A", "B" and "C".
> >
> > On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > > removed.
> > >
> > > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > > also possible, and so it doesn't have to be eager.
> > >
> > > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <oao.hikaru@gmail.com>
> > > wrote:
> > >
> > > > How about this
> > > >
> > > > ```
> > > > for ( i of Array.range(1, 10) ) { ... }
> > > > // OR
> > > > for ( i of [1..10] )  { ... }
> > > > ```
> > > >
> > > >
> > > > ___
> > > > es-discuss mailing list
> > > > es-discuss@mozilla.org
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > > >
> > >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Viktor Kronvall]

For `String.range` what would the expected result of
`String.range('A','zzz')` be?

Is an exhaustive pattern expected?

`['A','B','C',...'Z','a','b','c',...,'z','AA','AB',...]`
2016年11月3日(木) 19:21 Michael J. Ryan <track...@gmail.com>:

> If there's a Number.range, if suggest a corresponding String.range for
> character ranges...  Agreed on it being a utility function over me syntax.
>
> On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:
>
> If string ranges are based on character codes, it will (for the Latin
> alphabet, at least, not necessarily for other languages).
>
> I would prefer a function over syntax, though, since it would be more
> easily adopted (polyfill > syntax), and it would fit more idiomatically
> with the rest of the language (which also uses functions for most
> utilities).
>
> Maybe a `Number.range` would work?
>
> ```js
> Number.range = function *range(start, end=undefined, step=1) {
>   if (end === undefined) [start, end] = [0, start];
>   if (end === undefined) end = Infinity;
>   for (let i = 0; i < end; i += step) {
> yield i;
>   }
> };
> ```
>
> On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
>
> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> return a generator
> or at least something that extends a generator, though. I wonder if it's
> viable to implement
> something akin to `.length` on ranges, which could be natural numbers or
> `Infinity`.
>
> As for numbers, I don't see any issues. One issue that came up in the
> original thread was
> that string ranges may need a better definition, as ["A".."C"] might not
> necessarily transpile
> to be a generator that yields "A", "B" and "C".
>
> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > removed.
> >
> > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > also possible, and so it doesn't have to be eager.
> >
> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <oao.hikaru@gmail.com>
> > wrote:
> >
> > > How about this
> > >
> > > ```
> > > for ( i of Array.range(1, 10) ) { ... }
> > > // OR
> > > for ( i of [1..10] )  { ... }
> > > ```
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Michael J. Ryan]

If there's a Number.range, if suggest a corresponding String.range for
character ranges...  Agreed on it being a utility function over me syntax.

On Nov 3, 2016 10:25 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote:

> If string ranges are based on character codes, it will (for the Latin
> alphabet, at least, not necessarily for other languages).
>
> I would prefer a function over syntax, though, since it would be more
> easily adopted (polyfill > syntax), and it would fit more idiomatically
> with the rest of the language (which also uses functions for most
> utilities).
>
> Maybe a `Number.range` would work?
>
> ```js
> Number.range = function *range(start, end=undefined, step=1) {
>   if (end === undefined) [start, end] = [0, start];
>   if (end === undefined) end = Infinity;
>   for (let i = 0; i < end; i += step) {
> yield i;
>   }
> };
> ```
>
> On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:
>
>> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
>> return a generator
>> or at least something that extends a generator, though. I wonder if it's
>> viable to implement
>> something akin to `.length` on ranges, which could be natural numbers or
>> `Infinity`.
>>
>> As for numbers, I don't see any issues. One issue that came up in the
>> original thread was
>> that string ranges may need a better definition, as ["A".."C"] might not
>> necessarily transpile
>> to be a generator that yields "A", "B" and "C".
>>
>> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
>> > I'll note, just for clarity, that Scala's `1 to 10` is technically just
>> a
>> > normal method call equivalent to `(1).to(10)`, with optional parentheses
>> > removed.
>> >
>> > Also, I'd prefer this to be a generator instead, so infinite ranges are
>> > also possible, and so it doesn't have to be eager.
>> >
>> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <oao.hikaru@gmail.com>
>> > wrote:
>> >
>> > > How about this
>> > >
>> > > ```
>> > > for ( i of Array.range(1, 10) ) { ... }
>> > > // OR
>> > > for ( i of [1..10] )  { ... }
>> > > ```
>> > >
>> > >
>> > > ___
>> > > es-discuss mailing list
>> > > es-discuss@mozilla.org
>> > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> >
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Isiah Meadows]

If string ranges are based on character codes, it will (for the Latin
alphabet, at least, not necessarily for other languages).

I would prefer a function over syntax, though, since it would be more
easily adopted (polyfill > syntax), and it would fit more idiomatically
with the rest of the language (which also uses functions for most
utilities).

Maybe a `Number.range` would work?

```js
Number.range = function *range(start, end=undefined, step=1) {
  if (end === undefined) [start, end] = [0, start];
  if (end === undefined) end = Infinity;
  for (let i = 0; i < end; i += step) {
yield i;
  }
};
```

On Thu, Nov 3, 2016, 12:56 kdex <k...@kdex.de> wrote:

> Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just
> return a generator
> or at least something that extends a generator, though. I wonder if it's
> viable to implement
> something akin to `.length` on ranges, which could be natural numbers or
> `Infinity`.
>
> As for numbers, I don't see any issues. One issue that came up in the
> original thread was
> that string ranges may need a better definition, as ["A".."C"] might not
> necessarily transpile
> to be a generator that yields "A", "B" and "C".
>
> On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> > I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> > normal method call equivalent to `(1).to(10)`, with optional parentheses
> > removed.
> >
> > Also, I'd prefer this to be a generator instead, so infinite ranges are
> > also possible, and so it doesn't have to be eager.
> >
> > On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <oao.hikaru@gmail.com>
> > wrote:
> >
> > > How about this
> > >
> > > ```
> > > for ( i of Array.range(1, 10) ) { ... }
> > > // OR
> > > for ( i of [1..10] )  { ... }
> > > ```
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[kdex]

Agreed. There's no reason why `Array.range` or `[1..10]` couldn't just return a 
generator
or at least something that extends a generator, though. I wonder if it's viable 
to implement
something akin to `.length` on ranges, which could be natural numbers or 
`Infinity`.

As for numbers, I don't see any issues. One issue that came up in the original 
thread was
that string ranges may need a better definition, as ["A".."C"] might not 
necessarily transpile
to be a generator that yields "A", "B" and "C".

On Thursday, November 3, 2016 4:46:03 PM CET Isiah Meadows wrote:
> I'll note, just for clarity, that Scala's `1 to 10` is technically just a
> normal method call equivalent to `(1).to(10)`, with optional parentheses
> removed.
> 
> Also, I'd prefer this to be a generator instead, so infinite ranges are
> also possible, and so it doesn't have to be eager.
> 
> On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <oao.hikaru@gmail.com>
> wrote:
> 
> > How about this
> >
> > ```
> > for ( i of Array.range(1, 10) ) { ... }
> > // OR
> > for ( i of [1..10] )  { ... }
> > ```
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Isiah Meadows]

I'll note, just for clarity, that Scala's `1 to 10` is technically just a
normal method call equivalent to `(1).to(10)`, with optional parentheses
removed.

Also, I'd prefer this to be a generator instead, so infinite ranges are
also possible, and so it doesn't have to be eager.

On Thu, Nov 3, 2016, 11:52 Hikaru Nakashima <oao.hikaru@gmail.com>
wrote:

> How about this
>
> ```
> for ( i of Array.range(1, 10) ) { ... }
> // OR
> for ( i of [1..10] )  { ... }
> ```
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ranges

[Hikaru Nakashima]

How about this

```
for ( i of Array.range(1, 10) ) { ... }
// OR
for ( i of [1..10] )  { ... }
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Ranges

[kdex]

A few months ago, there was a thread on ESDiscuss [1] where somebody asked for 
native `Range` support,
i.e. numeric ranges, string ranges, etc.

It seems like it didn't receive much attention, so I'd like to bring this up 
for discussion again.

If you were to iterate from X to Y, you would usually use a `for` loop that 
uses a loop variable `i`,
which you would declare with `let`. You can't use `const`, since you'll have to 
increment it, and you
don't want to use `var`, because it makes no sense to make a reference to `i` 
outside of the loop,
unless you were to re-use the loop variable for further loops.

In other words, you're forced to choose a scope where other scopes barely make 
any sense.
Having a for-loop that abstracts over this needless explicitness could help 
make the concept of
iteration more declarative.

Python has `range()` (but no for loops that create ranges) [2], and Scala 
introduced two for-loop syntaxes
that will create ranges for you:

```scala
for (i <- 1 to 10) { … } // 10 inclusive
for (i <- 1 until 10) { … } // 10 exclusive
```

There's a plethora of npm packages that implement ranges, the most popular one 
apparently being `fill-range`
with 7.4 million downloads a month, so it seems that the community would 
appreciate native support a lot.

I've searched through some proposals, but couldn't find anyone currently 
writing a spec for it.
Is there general interest for ranges at TC39? It struck me as odd that the only 
thing I found about them in ES was [1].

[1] https://esdiscuss.org/topic/feature-request-add-range-type-data
[2] https://docs.python.org/3/library/functions.html#func-range
[3] https://www.npmjs.com/package/fill-range
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Array method ranges

[Peter van der Zee]

What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.

As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?

arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);

arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards

Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).

arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)

Of course, it would still skip the holes in sparse arrays.

- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Array method ranges

[François REMY]

Good idea. However, I don't like the fact arr.forEach(f,null,-1,0) doesn't 
walk the array backwards properly. Not sure it's worth to have it built-in 
though.


 Date: Thu, 24 Jan 2013 12:06:23 +0100
 Subject: Array method ranges
 From: e...@qfox.nl
 To: es-discuss@mozilla.org

 What about adding specific range arguments to the es5 array methods
 (forEach, map, etc)? Currently the start (inclusive) and stop
 (exclusive) is always 0 ... length, but what if you only want to map
 over a sub range of the array? Or maybe I want to traverse the array
 in reverse? I'd either have to slice it or .reverse it, neither are
 something I would want. So I fall back to `for` or `while` loops.

 As for the context parameter, I believe undefined won't change the
 context opposed to omitting it, right?

 arr.forEach(function(){ ...});
 // same as
 arr.forEach(function(){ ...}, undefined, 0, arr.length);

 arr.slice(10,10).forEach...
 arr.slice(80,20).reverse().forEach...
 =
 arr.forEach(function(){ ...}, undefined, 10, 20);
 arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
 80, backwards

 Negative numbers could behave the same as in slice (offsets from the
 last item, rather than the first).

 arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
 arr.forEach(function(){ ...}, undefined, -20, -10); // run from
 length-20 to length-10 (so, forward)
 arr.forEach(function(){ ...}, undefined, -20, -30); // run from
 length-20 to length-30 (so, backwards)

 Of course, it would still skip the holes in sparse arrays.

 - peter
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss  
   
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array method ranges

[Erik Arvidsson]

At this point I think we are better of moving towards iterator
methods. For example if we had an islice like the one in Python's
itertools [*] we can do:

for (let v of islice(arr, start, stop)) {
  ...
}

this would be equivalent to your proposed

arr.forEach((v) = { ... }, undefined, start, stop)

with the benefit that it composes much better.

[*] http://docs.python.org/2/library/itertools.html#itertools.islice

On Thu, Jan 24, 2013 at 9:45 AM, François REMY
francois.remy@outlook.com wrote:
 Good idea. However, I don't like the fact arr.forEach(f,null,-1,0) doesn't 
 walk the array backwards properly. Not sure it's worth to have it built-in 
 though.

 
 Date: Thu, 24 Jan 2013 12:06:23 +0100
 Subject: Array method ranges
 From: e...@qfox.nl
 To: es-discuss@mozilla.org

 What about adding specific range arguments to the es5 array methods
 (forEach, map, etc)? Currently the start (inclusive) and stop
 (exclusive) is always 0 ... length, but what if you only want to map
 over a sub range of the array? Or maybe I want to traverse the array
 in reverse? I'd either have to slice it or .reverse it, neither are
 something I would want. So I fall back to `for` or `while` loops.

 As for the context parameter, I believe undefined won't change the
 context opposed to omitting it, right?

 arr.forEach(function(){ ...});
 // same as
 arr.forEach(function(){ ...}, undefined, 0, arr.length);

 arr.slice(10,10).forEach...
 arr.slice(80,20).reverse().forEach...
 =
 arr.forEach(function(){ ...}, undefined, 10, 20);
 arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
 80, backwards

 Negative numbers could behave the same as in slice (offsets from the
 last item, rather than the first).

 arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to 
 length
 arr.forEach(function(){ ...}, undefined, -20, -10); // run from
 length-20 to length-10 (so, forward)
 arr.forEach(function(){ ...}, undefined, -20, -30); // run from
 length-20 to length-30 (so, backwards)

 Of course, it would still skip the holes in sparse arrays.

 - peter
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss



-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array method ranges

[Brendan Eich]

Yes, this was the plan. I don't see a strawman, yet. Cc'ing jorendorff.

/be

Erik Arvidsson wrote:

At this point I think we are better of moving towards iterator
methods. For example if we had an islice like the one in Python's
itertools [*] we can do:

for (let v of islice(arr, start, stop)) {
   ...
}

this would be equivalent to your proposed

arr.forEach((v) =  { ... }, undefined, start, stop)

with the benefit that it composes much better.

[*] http://docs.python.org/2/library/itertools.html#itertools.islice

On Thu, Jan 24, 2013 at 9:45 AM, François REMY
francois.remy@outlook.com  wrote:

Good idea. However, I don't like the fact arr.forEach(f,null,-1,0) doesn't 
walk the array backwards properly. Not sure it's worth to have it built-in though.



Date: Thu, 24 Jan 2013 12:06:23 +0100
Subject: Array method ranges
From: e...@qfox.nl
To: es-discuss@mozilla.org

What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.

As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?

arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);

arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards

Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).

arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)

Of course, it would still skip the holes in sparse arrays.

- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array method ranges

[Brandon Benvie]

It looks like the beginnings of an outline were added to the standard
modules list living under '@iter' with zip and unzip so far:
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard. But no
separate strawman yet.

On Thursday, January 24, 2013, Brendan Eich wrote:

 Yes, this was the plan. I don't see a strawman, yet. Cc'ing jorendorff.

 /be

 Erik Arvidsson wrote:

 At this point I think we are better of moving towards iterator
 methods. For example if we had an islice like the one in Python's
 itertools [*] we can do:

 for (let v of islice(arr, start, stop)) {
...
 }

 this would be equivalent to your proposed

 arr.forEach((v) =  { ... }, undefined, start, stop)

 with the benefit that it composes much better.

 [*] 
 http://docs.python.org/2/**library/itertools.html#**itertools.islicehttp://docs.python.org/2/library/itertools.html#itertools.islice

 On Thu, Jan 24, 2013 at 9:45 AM, François REMY
 francois.remy@outlook.com  wrote:

 Good idea. However, I don't like the fact arr.forEach(f,null,-1,0)
 doesn't walk the array backwards properly. Not sure it's worth to have it
 built-in though.

 --**--

 Date: Thu, 24 Jan 2013 12:06:23 +0100
 Subject: Array method ranges
 From: e...@qfox.nl
 To: es-discuss@mozilla.org

 What about adding specific range arguments to the es5 array methods
 (forEach, map, etc)? Currently the start (inclusive) and stop
 (exclusive) is always 0 ... length, but what if you only want to map
 over a sub range of the array? Or maybe I want to traverse the array
 in reverse? I'd either have to slice it or .reverse it, neither are
 something I would want. So I fall back to `for` or `while` loops.

 As for the context parameter, I believe undefined won't change the
 context opposed to omitting it, right?

 arr.forEach(function(){ ...});
 // same as
 arr.forEach(function(){ ...}, undefined, 0, arr.length);

 arr.slice(10,10).forEach...
 arr.slice(80,20).reverse().**forEach...
 =
 arr.forEach(function(){ ...}, undefined, 10, 20);
 arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
 80, backwards

 Negative numbers could behave the same as in slice (offsets from the
 last item, rather than the first).

 arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to
 length
 arr.forEach(function(){ ...}, undefined, -20, -10); // run from
 length-20 to length-10 (so, forward)
 arr.forEach(function(){ ...}, undefined, -20, -30); // run from
 length-20 to length-30 (so, backwards)

 Of course, it would still skip the holes in sparse arrays.

 - peter
 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss




  __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss