Hacker News Reader

Comment by jashkenas | Hacker News Reader

Very much looking forward to seeing how this turns out. To view a list of some of the public-facing things Michael wants to change, take a look here:

https://github.com/michaelficarra/coffee-of-my-dreams

View on HN

He wants to remove semicolons except where absolutely necessary?

Is he nuts? The compiled output shouldn't be relying on an error-correction feature. Especially since it might break minifiers and validators.

That would just be a default in my fork. Since the output will be massively configurable, you can use any style you can imagine, including a single line with all the braces and semicolons and whitespace you want. See http://oai.cwi.nl/oai/asset/10876/10876D.pdf for a resource on defining grammars for AST to CST transformations.

I'm not sure I agree that ASI is an "error-correction feature". Die-hard always-semicolon advocates certainly would like to paint it that way, but I think that may be rewriting history a bit.

The ECMAscript standard[1] and the creator of the language[2] are pretty clear about it. From what I know of parsing, anything phrased in terms of adding tokens post-lexing in order to make an invalid parse tree valid as opposed to encoding the semantics in the grammar itself is most definitely an error correction method.

I think that a lot of the confusion comes from taking the term "error" personally. Nobody wants to be told that their programming style relies on "error correction" to be parsed, but it's just an implementation detail of the parser, not some kind of qualitative statement about your programming skills. Changing the name does not change how the parser works, and does not make anyone involved a better or worse programmer.

[1]: http://www.ecma-international.org/publications/files/ECMA-ST... (PDF) , section 7.9

[2]: http://brendaneich.com/2012/04/the-infernal-semicolon/, specifically "The moral of this story: ASI is (formally speaking) a syntactic error correction procedure."

Fair enough, but a statement like "compiled output shouldn't be relying on an error-correction feature" is only (self-evidently) true if we're using the informal, taking-it-personally connotations of "error correction".

I recognize the minifier significance. But wait, there are validators (!?) that choke on valid (!) syntax?

Lacking semicolons is an error, most validators error on it unless you tell them to ignore it.

Also, any minifier that turns valid javascript into invalid javascript is broken, full stop.

Yes yes, but some do, it was a giant flame war, and I'll admit that it can be a practical issue (if not a correctness one) for javascript to rely on automatic semicolon insertion if it means you can't use your minifier of choice.

But trying to use a "validator" that validates a languages other than the one you are writing is just plain insane.

I just want to make sure people know that those changes are bound for a fork once I reach full compliance with the current compiler. The project's one and only goal is to implement the language exactly as Jeremy's compiler does, but be prettier underneath (more extensible, versatile, configurable, robust, etc).

For those who don't want to wait, most of the public-facing changes listed there are already in LiveScript (http://gkz.github.com/LiveScript/) - though with a few more (in my opinion well justified) incompatibilities.

Reply on news.ycombinator.com