Re: Support underscores in numbers

[Alexander Craggs]

Oops, I'm an idiot and didn't see this.
On 26/07/2017 21:49:11, Logan Smyth <loganfsm...@gmail.com> wrote:
There is currently an active proposal for this: 
https://github.com/tc39/proposal-numeric-separator 
[https://github.com/tc39/proposal-numeric-separator]

On Wed, Jul 26, 2017 at 1:47 PM, Alexander Craggs <alexan...@debenclipper.com 
[mailto:alexan...@debenclipper.com]> wrote:

Large number are hard to read in JavaScript, is 2384923842 over a billion? Or 
just several hundred million. One solution to this some languages have used is 
to allow underscores within numbers. You can immediately recognise 
2_384_923_842 is a number in the billions, rather than millions.

It would be nice to have such delimiters in large numbers in JavaScript as 
well, and I don't think it would be breaking.

___
es-discuss mailing list
es-discuss@mozilla.org [mailto:es-discuss@mozilla.org]
https://mail.mozilla.org/listinfo/es-discuss 
[https://mail.mozilla.org/listinfo/es-discuss]


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Support underscores in numbers

[Alexander Craggs]

Large number are hard to read in JavaScript, is 2384923842 over a billion?  Or 
just several hundred million.  One solution to this some languages have used is 
to allow underscores within numbers. You can immediately recognise 
2_384_923_842 is a number in the billions, rather than millions.

It would be nice to have such delimiters in large numbers in JavaScript as 
well, and I don't think it would be breaking.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Migrating to a better communication tool

[Alexander Craggs]

Thought I'd move the topic of a new communication tool to it's own thread.  So 
that it doesn't pollute the (already polluted) removal of language features 
thread.

I took agree with Mark, I think it's time to move away from a mailing list and 
the obvious choice for discussions like this is a forum.  Discourse is one 
option, but I'd also like to put our NodeBB[0] as another option.

Thoughts of how it might be better than the current mailing list:

 - Doesn't pollute my inbox, option to subscribe and unsubscribe to particular 
threads.

 - Stops replies from showing up on some mail clients 
(https://puu.sh/wThmq/ae276dd806.png)

 - Universal formatting.  esdiscuss.org seems to break formatting sometimes (or 
put it in an attachement).

Negatives:

 - People who already have a good system setup for mailing lists will have to 
get used to working with a forum system.

 - Will require either a OAuth account (Github perhaps?) or an extra username 
and password.

[0] https://github.com/NodeBB/NodeBB
I hope more people read and search https://esdiscuss.org 
[https://esdiscuss.org/]/ and engage with history instead of coming as if to a 
blank slate.

In all fairness, es-discuss is rather ancient in the way it works. I personally 
would recommend es-discuss coming up with a better way to keep track of its 
threads. The current setup is rather confusing, imo. FWIW, I personally would 
recommend Discourse [https://www.discourse.org/]. I agree with you on the same 
topics coming up constantly though.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Alexander Craggs]

I'm sorry, I missed that suggestion.

That definitely sounds significantly better than a new MIME type.  Although two 
thoughts I have are:

 - How are you going to deal with scenarios that don't have extensions, e.g. 
REPL or inline JS.

 - Are extensions going to be released often, or is this going to be a one time 
thing?  For example, would we increment the version number with the current JS 
version (js6, js7 etc) and if so, would it make more sense to start on js7 
instead of js2?
On 25/07/2017 20:41:33, doodad-js Admin  wrote:
*  1. In terms of including it in 

Re: Removal of language features

[Alexander Craggs]

Some thoughts on using MIME types to distinguish between versions:

 1. In terms of including it in 

Re: JavaScript Versioning

[Alexander Craggs]

Huh, in which case I will!

What are your thoughts on the non-error message part of this proposal?
On 23/07/2017 06:34:48, Jordan Harband <ljh...@gmail.com> wrote:
Error messages 1) are unspecified, 2) change all the time, 3) vary by language, 
4) vary across browser/engine implementations. There is zero reason that any 
error message couldn't be changed, and in fact, many browsers do improve them 
over time.

I'd say before believing it can't be done, try filing tickets on Chromium, 
Webkit, SpiderMonkey, and Chakra, and see what the response is - you may get a 
more favorable response than you think.

On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs <alexan...@debenclipper.com 
[mailto:alexan...@debenclipper.com]> wrote:

(Apologies for the double email Jordan, I accidentally replied to just you, not 
es-discuss as well. I'm new to this whole mailing list thing.)

Apologies, that was a bad example. I was more considering "use strict" to be 
breaking in the sense that some things that worked without it would no longer 
work with it. That doesn't match the current scenario at all.

In terms of other threads giving reasons why no new modes were likely to be 
introduced, most that I could find appeared to fail in the sense of the content 
they provided, installing rules that were better found in a linter, as opposed 
to a parsing mode. Do you have any points on why the idea itself is unlikely to 
be implemented as opposed to the content?

I also feel that it is *impossible* for vendors to add such changes to make 
error messages more useful because in the JavaScript syntax specified ten years 
ago "await" didn't exist and it would just be an unexpected string. We would 
have to add some new detection feature for this newer flavour to allow better 
messages.

But error messages were the lowest suggestion for this new functionality, and 
probably another bad example. Just consider the hundreds of previously rejected 
proposals that were very promising but couldn't be used because of breaking 
backwards compatability.
On 23/07/2017 05:50:31, Jordan Harband <ljh...@gmail.com 
[mailto:ljh...@gmail.com]> wrote:
Strict mode wasn't a breaking change; browsers that don't understand strict 
mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be 
introduced.

There's also no need to add pragmas or make breaking changes to make error 
messages more useful; for that, I suggest filing specific suggestions on each 
engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <alexan...@debenclipper.com 
[mailto:alexan...@debenclipper.com]> wrote:

One of the main issues I've found with why a significant number of proposals 
are rejected is because it would introduce breaking changes into JavaScript, a 
language created over 22 years ago. It doesn't surprise me that people have 
suggestions to improve JavaScript that are breaking, popular syntax seems to 
have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header 
at the top of files. Would it not make sense to introduce new breaking changes 
under a similar header for each change we suggest? For example, "use es7" could 
allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so 
much more than we're currently able to, we'd no longer have to stick with 
useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

___
es-discuss mailing list
es-discuss@mozilla.org [mailto:es-discuss@mozilla.org]
https://mail.mozilla.org/listinfo/es-discuss 
[https://mail.mozilla.org/listinfo/es-discuss]



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Alexander Craggs]

(Apologies for the double email Jordan, I accidentally replied to just you, not 
es-discuss as well.  I'm new to this whole mailing list thing.)

Apologies, that was a bad example.  I was more considering "use strict" to be 
breaking in the sense that some things that worked without it would no longer 
work with it.  That doesn't match the current scenario at all.

In terms of other threads giving reasons why no new modes were likely to be 
introduced, most that I could find appeared to fail in the sense of the content 
they provided, installing rules that were better found in a linter, as opposed 
to a parsing mode.  Do you have any points on why the idea itself is unlikely 
to be implemented as opposed to the content?  

I also feel that it is *impossible* for vendors to add such changes to make 
error messages more useful because in the JavaScript syntax specified ten years 
ago "await" didn't exist and it would just be an unexpected string.  We would 
have to add some new detection feature for this newer flavour to allow better 
messages.

But error messages were the lowest suggestion for this new functionality, and 
probably another bad example.  Just consider the hundreds of previously 
rejected proposals that were very promising but couldn't be used because of 
breaking backwards compatability.
On 23/07/2017 05:50:31, Jordan Harband <ljh...@gmail.com> wrote:
Strict mode wasn't a breaking change; browsers that don't understand strict 
mode simply ignore the no-op string.

There's lots of other threads on why no new modes are likely to ever be 
introduced.

There's also no need to add pragmas or make breaking changes to make error 
messages more useful; for that, I suggest filing specific suggestions on each 
engine vendor's bug tracker.

On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <alexan...@debenclipper.com 
[mailto:alexan...@debenclipper.com]> wrote:

One of the main issues I've found with why a significant number of proposals 
are rejected is because it would introduce breaking changes into JavaScript, a 
language created over 22 years ago.  It doesn't surprise me that people have 
suggestions to improve JavaScript that are breaking, popular syntax seems to 
have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header 
at the top of files.  Would it not make sense to introduce new breaking changes 
under a similar header for each change we suggest?  For example, "use es7" 
could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so 
much more than we're currently able to, we'd no longer have to stick with 
useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```

___
es-discuss mailing list
es-discuss@mozilla.org [mailto:es-discuss@mozilla.org]
https://mail.mozilla.org/listinfo/es-discuss 
[https://mail.mozilla.org/listinfo/es-discuss]


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

JavaScript Versioning

[Alexander Craggs]

One of the main issues I've found with why a significant number of proposals 
are rejected is because it would introduce breaking changes into JavaScript, a 
language created over 22 years ago.  It doesn't surprise me that people have 
suggestions to improve JavaScript that are breaking, popular syntax seems to 
have changed significantly in those years.

We *did* introduce some breaking changes though, using the "use strict" header 
at the top of files.  Would it not make sense to introduce new breaking changes 
under a similar header for each change we suggest?  For example, "use es7" 
could allow people to say they are using the latest features.

Say we create such versioning, it would allow us to improve the language so 
much more than we're currently able to, we'd no longer have to stick with 
useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }
> Uncaught SyntaxError: Unexpected string
// Now...
< "use es7";
< function u() { let x = await "hi" }
> Uncaught SomeError: "await" keyword used outside of async function
```___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Add an easier method for slicing and stepping strings and arrays

[Alexander Craggs]

I always found the Python methodology of selecting characters from strings (or 
items from arrays) to be the most natural I've found among a number of language 
solutions.  Was considering whether adding the syntax would be beneficial for 
JavaScript.  For those who do not know, the syntax is as so:

```js
const str = 'example'
const arr = ['e', 'x', 'a', 'm', 'p', 'l', 'e']
// Single elements are selected as in JS:
str[1] // 'x'
arr[2] // 'a'
// Multiple elements are selected by providing two numbers, delimited by a colon
// The first number is inclusive, the last number is exclusive
str[1:3] // 'xa'
arr[3:6] // ['m', 'p', 'l']
// These numbers can also be negative, resulting in indexing from the end of 
the string/array
str[-1] // 'e'
str[-3:-1] // 'pl'
arr[-5:-3] // ['a', 'm']
arr[0:-5] // ['e', 'x']
// There is also a third number, which steps through the selection chosen by 
the first two
str[0:5:2] // 'eap'
// This number can be negative, which results in stepping backwards through the 
string/array
str[::-1] // 'elpmaxe'
// An empty item represents one of the following based upon it's position: 
[0:length:1]
```

The most official documentation I could find on this topic is from the Python 
tutorial [https://docs.python.org/3.6/tutorial/introduction.html#strings], a 
more useful reference however might be the Stack Overflow post on the topic 
[https://stackoverflow.com/questions/509211/explain-slice-notation].___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss