Hacker News new | comments | show | ask | jobs | submit login

I suppose I'm thinking of that as implementation details; from the perspective of languages, it appears ECMA-262 does specify a well-defined language. Any input string is either rejected (not in the language at all), or is mapped unambiguously to an abstract syntax tree. So from that perspective, any sequence of characters that gets you an abstract syntax tree is a program in the language! How precisely it gets mapped is "innards of the parser" if you view languages as just string->AST mappings.

The error-correction view seems to want to add a third category, strings that are in some sense "errors", but nonetheless get unambiguously mapped to an AST. Which is strange from a classical formal-languages view, because if a string gets mapped to an AST, it's in the language, and the procedure that mapped it constitutes the parser! That category seems more like "warnings" to me, i.e. you probably shouldn't do this, but it will produce a program if you do.

Yes, ECMA-262 completely specifies (modulo bugs) sentences that are accepted or rejected, and for those accepted, their meanings.

But that doesn't alter ASI's error-correction nature, which is not an "implementation detail" -- it's in the spec and all too observable.

You're right, it has the character of a warning system, like Dart's unsound "types". But if it had been noisy (consoles in the early days were costly), too many developers would have ignored the warnings, and users would have paid for the overhead.

Your concluding sentence is spot on, I agree people should use semicolons in JS. Relying on a Ruby-like coding style in the large is way too risky.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact