On 07/16/2015 13:35, Herby Vojčík wrote:
>
>
> Mark S. Miller wrote:
>> I echo this. E is a dynamic language with many similarities with JS,
>> including a similarly C-like syntax. In E I use
>> everything-is-a-pattern-or-expression all the time. When I first moved
>> to JS I missed it. Now that I am used to the JS
>> statements-are-not-expressions restrictions, I no longer do, with one
>> exception:
>>
>> When simply generating simple JS code from something else, this
>> restriction is a perpetual but minor annoyance. By itself, I would agree
>> that this annoyance is not important enough to add a new feature.
>> However, if rather than "adding a feature", we can explain the change as
>> "removing a restriction", then JS would get both simpler and more
>> powerful at the same time. Ideally, the test would be whether, when
>> explaining the less restrictive JS to a new programmer not familiar with
>> statement languages, this change results in one less thing to explain
>> rather than one more.
>
> I like the idea those it seems a bit dense and strange on the first look. One breaking change is, though, that before the change, semicolon inside parentheses is an error, which often catches the missing parenthesis; after the change it is not (and manifests itself only at the end of the file; or even two errors can cancel each other and make conforming JS but with different semantics).

That's my concern as well.  We'd be significantly complicating the syntax (and not in a clean way because the rules are not orthogonal), and densifying the space of valid but bizarre syntaxes.  More cases that used to be a simple syntax error can now turn into something grammatically correct but wrong.

This can also have adverse implications for lexing (the old / start-of-regexp-vs-division tokenization issue) and the potential for experimenting with macro systems, which are strongly negatively affected by anything that complicates the / issue in lexing.

     Waldemar

On 07/16/2015 13:35, Herby Vojčík wrote:

> I like the idea those it seems a bit dense and strange on the first look. One breaking change is, though, that before the change, semicolon inside parentheses is an error, which often catches the missing parenthesis; after the change it is not (and manifests itself only at the end of the file; or even two errors can cancel each other and make conforming JS but with different semantics).

That's my concern as well.  We'd be significantly complicating the syntax (and not in a clean way because the rules are not orthogonal), and densifying the space of valid but bizarre syntaxes.  More cases that used to be a simple syntax error can now turn into something grammatically correct but wrong.

This can also have adverse implications for lexing (the old / start-of-regexp-vs-division tokenization issue) and the potential for experimenting with macro systems, which are strongly negatively affected by anything that complicates the / issue in lexing.