ASI edits

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

ASI edits

Isiah Meadows-2
I know this is probably bad timing (considering [this PR][1] and the
fallout that followed), but I was thinking that it'd be nice if we
could insert a `[no LineTerminator here]` clause in a few places, to
remove some of the ASI hazards for those going semicolon-free, along
with some extras for consistency:

- Before the `[` in the second rule of [`MemberExpression`][2] and the
fourth rule of [`CallExpression`][3]
- Before `Arguments` in the last rule of [`MemberExpression`][2], the
third and sixth rule of [`CallExpression`][3], and
[`CoverCallExpressionAndAsyncArrowHead`][4]
- Before the `(` in [`FunctionDeclaration`][5],
[`FunctionExpression`][6], the first, fourth, and fifth rule of
[`MethodDefinition`][7], [`GeneratorMethod`][8], both rules in
[`GeneratorDeclaration`][9], and [`GeneratorFunction`][10]

One of the practical effects would be this: this source (taken from the spec):

```js
a = b + c
(d + e).print()
```

is currently interpreted as:

```js
a = b + c(d + e).print();
```

but would, with this proposal, be interpreted as this, which is a
*lot* more intuitive with what people would expect:

```js
a = b + c;
(d + e).print();
```

I know there's risk of web compat concerns, but I doubt they'd be
significant for anything that's not minified via the Closure Compiler
(which limits line length by default for reasons of old IE). Also, for
most non-ASI people, they probably just forgot a semicolon anyways,
and [here][11] is a concrete example of this, where ESLint was fixing
a linter violation incorrectly because it wasn't reading it as you'd
expect.

[1]: https://github.com/tc39/ecma262/pull/1062
[2]: https://tc39.github.io/ecma262/#prod-MemberExpression
[3]: https://tc39.github.io/ecma262/#prod-CallExpression
[4]: https://tc39.github.io/ecma262/#prod-CoverCallExpressionAndAsyncArrowHead
[5]: https://tc39.github.io/ecma262/#prod-FunctionDeclaration
[6]: https://tc39.github.io/ecma262/#prod-FunctionExpression
[7]: https://tc39.github.io/ecma262/#prod-MethodDefinition
[8]: https://tc39.github.io/ecma262/#prod-GeneratorMethod
[9]: https://tc39.github.io/ecma262/#prod-GeneratorDeclaration
[10]: https://tc39.github.io/ecma262/#prod-GeneratorExpression
[11]: https://github.com/eslint/eslint/issues/7787

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ASI edits

Claude Pache


Le 12 janv. 2018 à 22:09, Isiah Meadows <[hidden email]> a écrit :

I know this is probably bad timing (considering [this PR][1] and the
fallout that followed), but I was thinking that it'd be nice if we
could insert a `[no LineTerminator here]` clause in a few places, to
remove some of the ASI hazards for those going semicolon-free, along
with some extras for consistency:

- Before the `[` in the second rule of [`MemberExpression`][2] and the
fourth rule of [`CallExpression`][3]
- Before `Arguments` in the last rule of [`MemberExpression`][2], the
third and sixth rule of [`CallExpression`][3], and
[`CoverCallExpressionAndAsyncArrowHead`][4]
- Before the `(` in [`FunctionDeclaration`][5],
[`FunctionExpression`][6], the first, fourth, and fifth rule of
[`MethodDefinition`][7], [`GeneratorMethod`][8], both rules in
[`GeneratorDeclaration`][9], and [`GeneratorFunction`][10]

One of the practical effects would be this: this source (taken from the spec):

```js
a = b + c
(d + e).print()
```

is currently interpreted as:

```js
a = b + c(d + e).print();
```

but would, with this proposal, be interpreted as this, which is a
*lot* more intuitive with what people would expect:

```js
a = b + c;
(d + e).print();
```

I know there's risk of web compat concerns, but I doubt they'd be
significant for anything that's not minified via the Closure Compiler
(which limits line length by default for reasons of old IE). Also, for
most non-ASI people, they probably just forgot a semicolon anyways,
and [here][11] is a concrete example of this, where ESLint was fixing
a linter violation incorrectly because it wasn't reading it as you'd
expect.

I think that the BC incompatibility issue is more than just a risk. I recall (but I couldn’t find it) that someone gave the example of some library that reads better when used as:

```js
foo
  (bar)
  (baz)
```

Also, cases you have forgotten, and where I *really* wish there be a [NLTH] rule, are *after* some contextual keywords that are used in prefix position, namely `get`, `set` and `static` (as it is already the case for `async`). See https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies for context. This is not only to satisfy my coding style, but also to ensure consistency when further contextual keywords will be added in the top level of class bodies, since those future keyword will require such a [NLTH] rule in order to be compatible with previously written field declarations that take advantage ASI.

—Claude




[1]: https://github.com/tc39/ecma262/pull/1062
[2]: https://tc39.github.io/ecma262/#prod-MemberExpression
[3]: https://tc39.github.io/ecma262/#prod-CallExpression
[4]: https://tc39.github.io/ecma262/#prod-CoverCallExpressionAndAsyncArrowHead
[5]: https://tc39.github.io/ecma262/#prod-FunctionDeclaration
[6]: https://tc39.github.io/ecma262/#prod-FunctionExpression
[7]: https://tc39.github.io/ecma262/#prod-MethodDefinition
[8]: https://tc39.github.io/ecma262/#prod-GeneratorMethod
[9]: https://tc39.github.io/ecma262/#prod-GeneratorDeclaration
[10]: https://tc39.github.io/ecma262/#prod-GeneratorExpression
[11]: https://github.com/eslint/eslint/issues/7787

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
_______________________________________________
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: ASI edits

Isiah Meadows-2
Inline
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache <[hidden email]> wrote:

>
>
> Le 12 janv. 2018 à 22:09, Isiah Meadows <[hidden email]> a écrit :
>
> I know this is probably bad timing (considering [this PR][1] and the
> fallout that followed), but I was thinking that it'd be nice if we
> could insert a `[no LineTerminator here]` clause in a few places, to
> remove some of the ASI hazards for those going semicolon-free, along
> with some extras for consistency:
>
> - Before the `[` in the second rule of [`MemberExpression`][2] and the
> fourth rule of [`CallExpression`][3]
> - Before `Arguments` in the last rule of [`MemberExpression`][2], the
> third and sixth rule of [`CallExpression`][3], and
> [`CoverCallExpressionAndAsyncArrowHead`][4]
> - Before the `(` in [`FunctionDeclaration`][5],
> [`FunctionExpression`][6], the first, fourth, and fifth rule of
> [`MethodDefinition`][7], [`GeneratorMethod`][8], both rules in
> [`GeneratorDeclaration`][9], and [`GeneratorFunction`][10]
>
> One of the practical effects would be this: this source (taken from the
> spec):
>
> ```js
> a = b + c
> (d + e).print()
> ```
>
> is currently interpreted as:
>
> ```js
> a = b + c(d + e).print();
> ```
>
> but would, with this proposal, be interpreted as this, which is a
> *lot* more intuitive with what people would expect:
>
> ```js
> a = b + c;
> (d + e).print();
> ```
>
> I know there's risk of web compat concerns, but I doubt they'd be
> significant for anything that's not minified via the Closure Compiler
> (which limits line length by default for reasons of old IE). Also, for
> most non-ASI people, they probably just forgot a semicolon anyways,
> and [here][11] is a concrete example of this, where ESLint was fixing
> a linter violation incorrectly because it wasn't reading it as you'd
> expect.
>
>
> I think that the BC incompatibility issue is more than just a risk. I recall
> (but I couldn’t find it) that someone gave the example of some library that
> reads better when used as:
>
> ```js
> foo
>   (bar)
>   (baz)
> ```

Do you have any ideas where I could look to potentially find it? I've
never seen *that* kind of DSL before, and that's an interesting use
case I haven't considered.

>
> Also, cases you have forgotten, and where I *really* wish there be a [NLTH]
> rule, are *after* some contextual keywords that are used in prefix position,
> namely `get`, `set` and `static` (as it is already the case for `async`).
> See
> https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies
> for context. This is not only to satisfy my coding style, but also to ensure
> consistency when further contextual keywords will be added in the top level
> of class bodies, since those future keyword will require such a [NLTH] rule
> in order to be compatible with previously written field declarations that
> take advantage ASI.

I thought about those, and I would ideally like those to be similarly
chnaged, but I decided against including them in this particular
proposal, since I wanted to focus on `[` and `(`, and I wasn't as keen
on web compat (considering it's actually a style many people prefer).
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ASI edits

Claude Pache


Le 14 janv. 2018 à 03:31, Isiah Meadows <[hidden email]> a écrit :

Inline
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache <[hidden email]> wrote:


Le 12 janv. 2018 à 22:09, Isiah Meadows <[hidden email]> a écrit :

I know this is probably bad timing (considering [this PR][1] and the
fallout that followed), but I was thinking that it'd be nice if we
could insert a `[no LineTerminator here]` clause in a few places, to
remove some of the ASI hazards for those going semicolon-free, along
with some extras for consistency:

- Before the `[` in the second rule of [`MemberExpression`][2] and the
fourth rule of [`CallExpression`][3]
- Before `Arguments` in the last rule of [`MemberExpression`][2], the
third and sixth rule of [`CallExpression`][3], and
[`CoverCallExpressionAndAsyncArrowHead`][4]
- Before the `(` in [`FunctionDeclaration`][5],
[`FunctionExpression`][6], the first, fourth, and fifth rule of
[`MethodDefinition`][7], [`GeneratorMethod`][8], both rules in
[`GeneratorDeclaration`][9], and [`GeneratorFunction`][10]

One of the practical effects would be this: this source (taken from the
spec):

```js
a = b + c
(d + e).print()
```

is currently interpreted as:

```js
a = b + c(d + e).print();
```

but would, with this proposal, be interpreted as this, which is a
*lot* more intuitive with what people would expect:

```js
a = b + c;
(d + e).print();
```

I know there's risk of web compat concerns, but I doubt they'd be
significant for anything that's not minified via the Closure Compiler
(which limits line length by default for reasons of old IE). Also, for
most non-ASI people, they probably just forgot a semicolon anyways,
and [here][11] is a concrete example of this, where ESLint was fixing
a linter violation incorrectly because it wasn't reading it as you'd
expect.


I think that the BC incompatibility issue is more than just a risk. I recall
(but I couldn’t find it) that someone gave the example of some library that
reads better when used as:

```js
foo
 (bar)
 (baz)
```

Do you have any ideas where I could look to potentially find it? I've
never seen *that* kind of DSL before, and that's an interesting use
case I haven't considered.

I’ve finally found, see:

Maybe not a significant example, but don’t underestimate the creativity of hackers.



Also, cases you have forgotten, and where I *really* wish there be a [NLTH]
rule, are *after* some contextual keywords that are used in prefix position,
namely `get`, `set` and `static` (as it is already the case for `async`).
See
https://tc39.github.io/proposal-class-fields/#sec-asi-hazards-in-class-bodies
for context. This is not only to satisfy my coding style, but also to ensure
consistency when further contextual keywords will be added in the top level
of class bodies, since those future keyword will require such a [NLTH] rule
in order to be compatible with previously written field declarations that
take advantage ASI.

I thought about those, and I would ideally like those to be similarly
chnaged, but I decided against including them in this particular
proposal, since I wanted to focus on `[` and `(`, and I wasn't as keen
on web compat (considering it's actually a style many people prefer).

As someone who uses semicolon-less style, `[`, `(` and other punctuation marks are not issues, but `get`, `set` and `static` in class fields are. My analysis:

But regardless of your coding style, the historical behaviour of `get`, `set` and `static` in classes introduces some irregularity, which is always bad, while `(` and `[` do not:

```js
class C {
    post // implicit semicolon here
    foo () { }
}

class D {
    get // no implicit semicolon here
    foo () { }
}

```

There are also issues around `in` and `instanceof`, but those are more likely to produce a syntax error in case of non-working ASI, and I think they are more problematic to correct.

—Claude




—Claude




[1]: https://github.com/tc39/ecma262/pull/1062
[2]: https://tc39.github.io/ecma262/#prod-MemberExpression
[3]: https://tc39.github.io/ecma262/#prod-CallExpression
[4]:
https://tc39.github.io/ecma262/#prod-CoverCallExpressionAndAsyncArrowHead
[5]: https://tc39.github.io/ecma262/#prod-FunctionDeclaration
[6]: https://tc39.github.io/ecma262/#prod-FunctionExpression
[7]: https://tc39.github.io/ecma262/#prod-MethodDefinition
[8]: https://tc39.github.io/ecma262/#prod-GeneratorMethod
[9]: https://tc39.github.io/ecma262/#prod-GeneratorDeclaration
[10]: https://tc39.github.io/ecma262/#prod-GeneratorExpression
[11]: https://github.com/eslint/eslint/issues/7787

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
_______________________________________________
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: ASI edits

Michael Haufe-2
In reply to this post by Isiah Meadows-2
Matt Might's MC Lexer is one example of a currying based DSL:

<http://matt.might.net/articles/lexing-and-syntax-highlighting-in-javascript/>

For example, to emulate what Lex provides:

// state (regex) (action) ;
<INIT>   [_A-Za-z]+    { return(ID) ; }
<INIT>   [0-9]+        { return(NUM) ; } 

in JavaScript you'd do:

INIT    (/[_A-Za-z]+/)    (function () { return ID ; }) ;
INIT    (/[0-9]+/)        (function () { return NUM ; }) ;

or more modernly:

INIT    (/[_A-Za-z]+/)    (() => ID );
INIT    (/[0-9]+/)        (() => NUM ) ;


On Sat, Jan 13, 2018 at 8:31 PM, Isiah Meadows <[hidden email]> wrote:

On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache <[hidden email]> wrote:
>
> [...]
>
> I think that the BC incompatibility issue is more than just a risk. I recall
> (but I couldn’t find it) that someone gave the example of some library that
> reads better when used as:
>
> ```js
> foo
>   (bar)
>   (baz)
> ```

Do you have any ideas where I could look to potentially find it? I've
never seen *that* kind of DSL before, and that's an interesting use
case I haven't considered.



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