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 <blueshuk2 at gmail.com> 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 <isiahmeadows at gmail.com>
> 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
>> me at isiahmeadows.com
>> www.isiahmeadows.com
>>
>> On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <
>> cyril.auburtin at 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 <alex at weej.com> 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 <jmar777 at gmail.com> 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.oao at 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 <andyearnshaw at gmail.com>:
>>>>>
>>>>> 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, <oao.hikaru.oao at gmail.com>
>>>>> 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 at mozilla.org
>>>>>
>>>>>
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>>
>>>>> es-discuss mailing list
>>>>>
>>>>>
>>>>> es-discuss at mozilla.org
>>>>>
>>>>>
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeremy Martin
>>>>> 661.312.3853 <(661)%20312-3853>
>>>>> http://devsmash.com
>>>>> @jmar777
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> es-discuss mailing list
>>>>>
>>>>> es-discuss at mozilla.org
>>>>>
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180630/7a911010/attachment-0001.html>