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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
