Ranges

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Ranges

Tab Atkins Jr.
On Tue, Dec 13, 2016 at 3:07 AM, Hikaru Nakashima
<[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Ranges

Andy Earnshaw-2

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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
661.312.3853
@jmar777

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________


es-discuss mailing list


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss






--
Jeremy Martin
661.312.3853
@jmar777




_______________________________________________

es-discuss mailing list

[hidden email]

https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________


es-discuss mailing list


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss






--
Jeremy Martin
661.312.3853
@jmar777




_______________________________________________

es-discuss mailing list

[hidden email]

https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Ranges

Isiah Meadows-2
In reply to this post by Cyril Auburtin
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.


On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________


es-discuss mailing list


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss






--
Jeremy Martin
661.312.3853
@jmar777




_______________________________________________

es-discuss mailing list

[hidden email]

https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________


es-discuss mailing list


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss






--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853
@jmar777




_______________________________________________

es-discuss mailing list

[hidden email]

https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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


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 <[hidden email]> 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 <[hidden email]> 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.

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss








_______________________________________________


es-discuss mailing list


[hidden email]


https://mail.mozilla.org/listinfo/es-discuss






--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853
@jmar777




_______________________________________________

es-discuss mailing list

[hidden email]

https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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


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 <[hidden email]> 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 <[hidden email]> 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.

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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


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 <[hidden email]> 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 <[hidden email]> 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.

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Ranges

Cyril Auburtin
s/possible benefits/possible performance benefits/ 
sorry

Le dim. 1 juil. 2018 à 18:13, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


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 <[hidden email]> 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 <[hidden email]> 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.

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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, <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Keeping proposals productive and increasing mailing list efficiency

Marky Mark
In reply to this post by Bob Myers

Bob Myers makes a great point in the following message he just recently posted on a totally unrelated thread. And I’d like to open a discussion up about it because I share his sentiments tremendously. I’ve been on this mailing list for quite a while now and while I do think its an awesome channel to discussed proposed solutions, I do see a large number of proposals and threads constantly being created that have already been discussed many many times.

The points below are great, however, I think its a partial solution to the real problem. I think the real problem includes the following:

  1. there is no easy way to access some sort of prerequisite or criteria before creating new threads. Does one even exist other than in people’s minds? I see there is an about page, but it doesn’t really have any checklist or recommendation of things to consider before opening a new thread. But even if it did, there is still the issue of accessibility which I identify in my next point….
  2. previous related conversations are not being considered because they are not prominent or easily found- they are kept in an archive that is totally separate from the email clients being used to facilitate these mailing list discussions. This means it is not likely that a person making a proposal, who is new to this mailing list format (which is mostly the case with new proposals), will even see the archives.

Another point: there are plenty of alternative solutions out there that would make this list much more usable and efficient (discourse, slack, GitHub etc), which have wide support and are reliable. Is there a reason why this list hasn’t embraced any of these newer technologies? Although not necessary, they offer strong feature sets that will make it quite easy to provide solutions to the above points.


On Sun, Jul 1, 2018 at 2:03 AM Bob Myers <[hidden email]> wrote:
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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Keeping proposals productive and increasing mailing list efficiency

Jerry Schulteis
One way to find related conversations is to add site:esdiscuss.org to the search terms.
E.g. "site:esdiscuss.org mailing list alternative":



Perhaps such a hint, as well as guidelines for self-vetting proposals before submitting, should appear in the list welcome message or the information page.



On Monday, July 2, 2018, 12:22:14 PM CDT, Mark <[hidden email]> wrote:


previous related conversations are not being considered because they are not prominent or easily found- they are kept in an archive that is totally separate from the email clients being used to facilitate these mailing list discussions. This means it is not likely that a person making a proposal, who is new to this mailing list format (which is mostly the case with new proposals), will even see the archives.

Another point: there are plenty of alternative solutions out there that would make this list much more usable and efficient (discourse, slack, GitHub etc), which have wide support and are reliable. Is there a reason why this list hasn’t embraced any of these newer technologies? Although not necessary, they offer strong feature sets that will make it quite easy to provide solutions to the above points.

_______________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Keeping proposals productive and increasing mailing list efficiency

Marky Mark
Yeah I looked at those but they are rather outdated. A lot of the pushback from moving to other platforms (ie. lack of mailing list features, forced browser usage, etc) are no longer the case and therefore dont really help explain why this list has avoided doing it for so long now.

On Mon, Jul 2, 2018, 3:12 PM Jerry Schulteis <[hidden email]> wrote:
One way to find related conversations is to add site:esdiscuss.org to the search terms.
E.g. "site:esdiscuss.org mailing list alternative":



Perhaps such a hint, as well as guidelines for self-vetting proposals before submitting, should appear in the list welcome message or the information page.



On Monday, July 2, 2018, 12:22:14 PM CDT, Mark <[hidden email]> wrote:


previous related conversations are not being considered because they are not prominent or easily found- they are kept in an archive that is totally separate from the email clients being used to facilitate these mailing list discussions. This means it is not likely that a person making a proposal, who is new to this mailing list format (which is mostly the case with new proposals), will even see the archives.

Another point: there are plenty of alternative solutions out there that would make this list much more usable and efficient (discourse, slack, GitHub etc), which have wide support and are reliable. Is there a reason why this list hasn’t embraced any of these newer technologies? Although not necessary, they offer strong feature sets that will make it quite easy to provide solutions to the above points.

_______________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Keeping proposals productive and increasing mailing list efficiency

Isiah Meadows-2
First, I found this resource that does clarify a *few* things, but it
doesn't go over details.

- https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#new-feature-proposals

Second, if you feel strongly enough, feel free to ping one of the
active committee members either through email or on #tc39 (on Freenode
IRC) to see about getting a little more clarification to the process.

Oh, and side note: one plus to having it email-only is that it's
easier to respond on-the-fly on mobile, and that's not quite so easy
when it's all on some platform thingy. (The list also isn't quite
active enough to merit the need for sorting and organization beyond
what https://esdiscuss.org/ provides.)

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Mon, Jul 2, 2018 at 3:19 PM, Mark <[hidden email]> wrote:

> Yeah I looked at those but they are rather outdated. A lot of the pushback
> from moving to other platforms (ie. lack of mailing list features, forced
> browser usage, etc) are no longer the case and therefore dont really help
> explain why this list has avoided doing it for so long now.
>
> On Mon, Jul 2, 2018, 3:12 PM Jerry Schulteis <[hidden email]> wrote:
>>
>> One way to find related conversations is to add site:esdiscuss.org to the
>> search terms.
>> E.g. "site:esdiscuss.org mailing list alternative":
>>
>>
>> https://esdiscuss.org/topic/meta-proposal-switch-es-discuss-from-a-mailing-list-to-using-the-tc39-github-issue-tracker-for-discussion
>>
>> https://esdiscuss.org/topic/move-es-discuss-to-discuss-webplatform-org
>>
>> Perhaps such a hint, as well as guidelines for self-vetting proposals
>> before submitting, should appear in the list welcome message or the
>> information page.
>>
>>
>>
>> On Monday, July 2, 2018, 12:22:14 PM CDT, Mark <[hidden email]> wrote:
>>
>>
>> previous related conversations are not being considered because they are
>> not prominent or easily found- they are kept in an archive that is totally
>> separate from the email clients being used to facilitate these mailing list
>> discussions. This means it is not likely that a person making a proposal,
>> who is new to this mailing list format (which is mostly the case with new
>> proposals), will even see the archives.
>>
>> Another point: there are plenty of alternative solutions out there that
>> would make this list much more usable and efficient (discourse, slack,
>> GitHub etc), which have wide support and are reliable. Is there a reason why
>> this list hasn’t embraced any of these newer technologies? Although not
>> necessary, they offer strong feature sets that will make it quite easy to
>> provide solutions to the above points.
>>
>> _______________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Keeping proposals productive and increasing mailing list efficiency

Jordan Harband
Ecma data - including the contents of this list - needs to live for decades in ecma's archives. Very few alternatives have the necessary staying power.

On Tue, Jul 3, 2018 at 6:05 PM, Isiah Meadows <[hidden email]> wrote:
First, I found this resource that does clarify a *few* things, but it
doesn't go over details.

- https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#new-feature-proposals

Second, if you feel strongly enough, feel free to ping one of the
active committee members either through email or on #tc39 (on Freenode
IRC) to see about getting a little more clarification to the process.

Oh, and side note: one plus to having it email-only is that it's
easier to respond on-the-fly on mobile, and that's not quite so easy
when it's all on some platform thingy. (The list also isn't quite
active enough to merit the need for sorting and organization beyond
what https://esdiscuss.org/ provides.)

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Mon, Jul 2, 2018 at 3:19 PM, Mark <[hidden email]> wrote:
> Yeah I looked at those but they are rather outdated. A lot of the pushback
> from moving to other platforms (ie. lack of mailing list features, forced
> browser usage, etc) are no longer the case and therefore dont really help
> explain why this list has avoided doing it for so long now.
>
> On Mon, Jul 2, 2018, 3:12 PM Jerry Schulteis <[hidden email]> wrote:
>>
>> One way to find related conversations is to add site:esdiscuss.org to the
>> search terms.
>> E.g. "site:esdiscuss.org mailing list alternative":
>>
>>
>> https://esdiscuss.org/topic/meta-proposal-switch-es-discuss-from-a-mailing-list-to-using-the-tc39-github-issue-tracker-for-discussion
>>
>> https://esdiscuss.org/topic/move-es-discuss-to-discuss-webplatform-org
>>
>> Perhaps such a hint, as well as guidelines for self-vetting proposals
>> before submitting, should appear in the list welcome message or the
>> information page.
>>
>>
>>
>> On Monday, July 2, 2018, 12:22:14 PM CDT, Mark <[hidden email]> wrote:
>>
>>
>> previous related conversations are not being considered because they are
>> not prominent or easily found- they are kept in an archive that is totally
>> separate from the email clients being used to facilitate these mailing list
>> discussions. This means it is not likely that a person making a proposal,
>> who is new to this mailing list format (which is mostly the case with new
>> proposals), will even see the archives.
>>
>> Another point: there are plenty of alternative solutions out there that
>> would make this list much more usable and efficient (discourse, slack,
>> GitHub etc), which have wide support and are reliable. Is there a reason why
>> this list hasn’t embraced any of these newer technologies? Although not
>> necessary, they offer strong feature sets that will make it quite easy to
>> provide solutions to the above points.
>>
>> _______________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123