cyril.auburtin at gmail.com (2018-07-02T18:13:34.456Z)
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 performance 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, for creating ranges. There are `Array.from({length: n}, (_, i) => doSomethingWwith(i))` or other similar non-obvious code for creating
ranges. A 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 seem to want generators for
this, I'd prefer not
Le dim. 1 juil. 2018 à 08:03, Bob Myers <rtm at gol.com> a écrit :cyril.auburtin at gmail.com (2018-07-01T16:24:00.516Z)
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 performance 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 seem to want generators for
this, I'd prefer not
Le dim. 1 juil. 2018 à 08:03, Bob Myers <rtm at gol.com> a écrit :cyril.auburtin at gmail.com (2018-07-01T16:21:55.991Z)
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 performance 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 :cyril.auburtin at gmail.com (2018-07-01T16:21:41.774Z)
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 performance 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 :
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/7e4e07a8/attachment-0001.html>