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 <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/3d13fc8e/attachment-0001.html>