- there is no rule-of-thumb understanding (programmers
have to look up or memorize all restricted productions,
Here is a quibble: there is a rule, or set of rules
.. Not quite as bad as you wrote.
Sorry, I didn't notice that my attempted summary could be
read as dramatizing the issue!-) The issue is overheated enough,
my intention was merely to be concise in giving an impression
of where I see the issues.
The bigger problem is not the rule-space but the mixed
significance and insignificance of line terminators.
..
.. The line terminator having
selective meaning due to ASI as an error correction procedure,
and of course in restricted productions, creates an expectation
that line terminators matter in general.
However, going down that road leads to CoffeeScript, or
(somewhat more conservatively due to the use of : at end
of head forms, and a lot older) Python. It's a steep slippery slope.
I was trying to point out that CoffeeScript, Python, Ruby, ..
all have subtly different systems, which in turn differ from
Haskell's system, and others in that space. It is not useful
to throw them into a single pigeon hole. The remainder
or your reply shows that you are aware of that, so I am
surprised that you start with this misleading statement!-)
It may be useful to look at the individual features of these
different systems, not to make Python/CoffeeScript/Haskell
coders feel at home, but to select a combination that fits
Javascript, and Javascript coders' expectations. And finally
stops getting in the way of Javascript language designers.
Good points. The keystroke tax with ; and {} in JS is an issue.
It is a tax at the margin on all effort creating and maintaining
source, though, so I expect over time lower-tax syntaxes to
win. The trick is migrating JS code into a new standardized
edition without creating new runtime errors by failing to
catch migration errors.
Understood.
Reformulating the spec could be done but we would need
to keep the "ES5" or "classic" ASI spec around. Spec
complexity and the opportunity cost of the work to increase
it in this area will hurt -- probably a lot.
Anyway, we'd need a more complete strawman spec to
evaluate, to get further.
Since this is likely material for ES/next/next, and the proposal
deadline for ES/next seems to be near, I'll focus on the callback
nesting issue first.
However, it would be useful to have a Javascript implementation
of a Javascript parser and unparser (precisely reproducing the
source). Then one could prototype such syntax modifications
as source-to-source translators, perhaps even testing whether
a rewrite changes parse-followed-by-unparse results.
There are lots of parsers, and some pretty-printers, but I'd like
it to be in Javascript (rather than in Haskell;-), so that some of
you are likely to use it, and it needs to work for me on Windows.
Or would you be happy if I used one of the Haskell libs for JS?-)
And blog posts seem to be more about trouble with ASI
than about usefulness of ASI [2,4,5].
Beware negativity and confirmation biases here.
If did my references correctly, those posts were explanatory,
in the direction: "you cannot avoid ASI, so you better understand
how it works".
ASI is relied on by tons of content, without complaints (or
praise). It goes without notice when it works, which is often
when a ; was left off where the formal grammar requires it.
Very likely. Coders may not even be aware when they rely
on ASI.
So ASI as it stands in Javascript
now does not only make life harder for programmers but
for spec writers (and readers), too.
The spec didn't change, so we are riding on that sunk cost.
I wasn't referring to the ASI spec. When browsing the list
archives, I noticed that discussions of syntax tend to drift
into parser issues, and sometimes, when contributors have
almost settled on a suggestion, out of nowhere comes an
ASI issue ("if we split this over two lines, it is going to be
ambiguous"). Or simple operator proposals such as modulo
operators have to consider restricted productions.
My impression was that ASI concerns are hampering
language development, because ASI doesn't operate
separately - it is entwined with the grammar.
It's easy to exaggerate here, but it seems to me the big
deal is not ASI costs already sunk. Rather it is how to
lighten the syntax and make ASI more usable, in a new
edition.
Agreed. I just wanted to point out that ASI costs are ongoing.
What we could use is some validated alternative that has
no runtime migration error gotchas.
But even if the alternative has a nice specification, how to
validate that it doesn't ruin people's coding patterns without
knowing what those coding patterns are?
HSI would need some tweaking to be suitable for Javascript
coding styles (though some tweaks could be copied from
Haskell, I just omitted them to bring out the core ideas).
I think your effort developing a draft spec would be great.
Good to know. No promises, though!-)
Still, such a variant might work better and be easier to
understand than the current ASI. Equally important, a
transition might be doable as incremental improvements
rather than a radically different system.
While new Harmony proposals will be prototyped and
even shipped before the next edition, it takes years to do
a new edition. So we do not have the luxury of many
*standardized* incremental improvements.
I was thinking about *non-standard* increments, just to
see how any theoretically nice changes hold up in practice,
before standardizing the successful candidates. Like
expression closure and let-expressions, the changes would
have to be marked as experimental/call-for-feedback only.
A pragma that lets developers trace when ASI kicks in
might raise awareness and understanding of ASI. Then
coders might be able to articulate what aspects of ASI
they rely on, and what aspects might be open to change.
A standalone tool that transforms Javascript source by
applying ASI, leaving everything else unchanged, would
also help. Developers could look at diffs, and compare
them to their expectations.
For instance, one could weaken the no-line-break-here
token to consider line-break plus indentation.
We tried this back at the July 2008 "Harmony" (Oslo) meeting.
..
However, we did not want to require the kind of analysis that
would be needed to distinguish
..
[return <break><space> string]
[return <break><space> expression]
In this case it is *not* safe to assume (per HSI) that the line
after the return is a continuation of the return statement.
There is mis-indented JS on the web, including of this form,
and what such code means (whatever was intended) is now
a compatibility constraint.
Yes. My suggestion was to take the assumptions out of the
game - no complicated analysis, just indentation. But one
would have to deprecate first, have tools warn developers
if they use coding patterns that are going to break, then
offer transition help. A longish process..
Again, we don't get standardized small steps. We need
something more than user-tested single-source new parser
code (a la CoffeeScript, which I admire -- just saying we
can't standardize anything like its lexer/disambiguator/parser
code). We need at least a "HSI for JS" spec with more details
than in your message, and (especially) careful analysis of
how migration would work.
I'm still skeptical this is (a) doable with only early errors
when migrating; (b) worth the up-front and ongoing costs,
since we will need to keep ASI spec'ed forever (for web
compatibility of not-opted-into-Harmony JS).
But since you wrote a nice post and seem motivated, I do
want to encourage you to work out more details.
Thanks for the useful explanations. It might be worth having
them on the wiki, as an ASI-non-proposal with rationale.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
