Ranges

[Cyril Auburtin]

s/possible benefits/possible performance benefits/
sorry

Le dim. 1 juil. 2018 à 18:13, Cyril Auburtin <cyril.auburtin at gmail.com> 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 <rtm at gol.com> 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 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 <cyril.auburtin at gmail.com>
>> 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 <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?
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180701/ef24500e/attachment-0001.html>