5 ms·

The key point: "ASI [“Automatic Semicolon Insertion”] is an error correction procedure. If you start to code as if it were a universal significant-newlin

The key point: "ASI [“Automatic Semicolon Insertion”] is an error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get into trouble."—Brendan Eich

enneff 15y ago
That doesn't sound right to me. Making s language's syntax more liberal is not a sane way to correct errors. If anything, JavaScript's ASI is an error creation mechanism.
- magicalist 15y ago
  Yes, he's acknowledged many times (including in this post) that it was a mistake. That was the intention, but it wasn't successful. It should have gone all in (no semicolons at all) or not have existed.
  - tolmasky 15y ago
    I think it was a reasonable decision at the time. The idea was that JavaScript was not going to be some language people wrote hundreds of thousands of lines of code in, and that the target audience would become frustrated if the language didn't "help" them. For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error: <a onClick = "someFunc()" > ... > Error, missing semicolon after ")" on line 1 That could get pretty annoying pretty fast, and simple little event handlers like these were probably the main use of JavaScript for the first x years. It also matched the existing philosophy of HTML which was to really go out of its way to make sense of whatever was in the file. Now of course, the constraints are different: people want to use JavaScript for huge codebases and serious projects, so it makes sense that these decisions are no longer appropriate.
    - masklinn 15y ago
      > For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error: Depends whether the semicolon is defined as a terminator or as a separator. This would be valid code with statement separator semicolons.
    - deleted 15y ago
      [deleted]
    - geoffschmidt 15y ago
      Couldn't the 'onClick' case have been solved by allowing either a statement or an expression to appear there?
- raganwald 15y ago
  "Here is your new apartment. You must use a key to enter it. If you forget your key, you can buzz the superintendent during business hours, and if the super is home, (s)he will open the door for you.” If you try to take your key with you at all times, the super will save your bacon once in a blue moon when you forget your key. On the other hand, if you think of the door as only needing a key when you wish to have it opened on nights and week-ends, you are on your way to trouble.
  - ronaldj 15y ago
    That's a great analogy.
    - groovy2shoes 15y ago
      The difference is that if you forget your key, you know that you forgot your key, and you have to actively call the superintendent to have them "save your bacon." With ASI, you might never know that you had forgotten your key.
      - eli 15y ago
        I agree that it would be nice to have something like "-Wall" that could warn you that you're doing things the "wrong way" but, uh, isn't that what JSLint is?
        deleted 15y ago
        [deleted]
    - jerf 15y ago
      That's a terrible analogy. What's the analog for receiving a syntax error instead when you "forget your keys"? The analogy gives you bizarre and wrong choices and tradeoffs. As usual, analogies do more harm than good, especially when understanding a relatively simple technical issue.
      - 15y ago
- spohlenz 15y ago
  I believe he refers to error correction as in it corrects errors in the code -- i.e. the code itself should have semicolons and is fixed through ASI.
  - BrendanEich 15y ago
    Right. To avoid confusion, I updated the post so the sentence reads "ASI is (formally speaking) a syntactic error correction procedure."
    - _delirium 15y ago
      Given that these are all formal languages, though, isn't that equivalent to saying that ASI is, formally speaking, part of the language's syntax? It's all just parsers! Apart from the social conventions around them, of course.
      - BrendanEich 15y ago
        No, there's an important distinction. ASI does not even kick in without a syntax error. Yet the "expectation of ASI" or (I think more likely) "expectation of newline significance" makes people believe that they'll get a ; inserted by separating two things by one or more newlines. Most languages do not specify error correction. HTML5 of course does; CSS too; among general programming languages it's much less common. The spec for ASI does not fit in the tried-and-true LR(1) formalism used by ECMA-262. Parsing is not all ad-hoc or equally well-formalized and proven. In addition to ASI, ECMA-262 has to use lookahead restrictions and a bit of semantic checking to cope with what could be purely syntactic concerns (say, if it could use GLR instead of LR(1)).
        _delirium 15y ago
        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.
chad_walters 15y ago
It's interesting because the 5.1 specification doesn't say it is an error correction mechanism, it states: "For convenience, however, such semicolons may be omitted from the source text in certain situations".
bmelton 15y ago
I think the other thing that goes unmentioned is that a single semi-colon on a line in a file would pretty much end this debate. Perhaps I've worked too much in teams, but surely "path of least resistance" has to factor some, right? I mean, if the choice is add a semi-colon to a line in a file versus asking somebody else to rewrite the compiler to be able to accept it, surely common sense would just be to add the semi-colon. It doesn't mean that you're wrong, or that your code is broken, or that Crockford is smarter than you... but now you have code that works and compiles and that people can use. Surely, that's gotta count for something, right?
- anonymoushn 15y ago
  Even if we inserted the semicolon, JSMin would still be broken :)
- tomjen3 15y ago
  No. Sure it is the easier solution right now. But in the long run that would mean the Crockford would be able to dictate the style of Javascript to whatever the hell he wants. Given how important Javascript is now (and will be in the future) we cannot allow any one person to retard the entire future. Anyway use Googles closure compiler -- it can actually handle Javascript.
  - bmelton 15y ago
    I think that's a visceral reaction based on his rudeness. So long as he keeps building tools and utilities that people rely on, and that people use, he is at least influencing the direction of Javascript and, knowing that, I'd think one might take heed when Crockford says "this will break in the future", as he happens to have more insight into the language than most. I understand that he wasn't polite, and I certainly understand the desire for the 'asshole' to be proven wrong. And maybe he is. Of course, that doesn't make him wrong, and it doesn't mean that he's "retarding the future" either, necessarily. But the fact that jsmin is perhaps the most widely deployed JS minification utility does matter, whether anyone chooses to accept it or not. And if you really think that he is retarding the future, the correct answer probably isn't to bicker about it on the internet, but to create a better compiler (or work on getting a better compiler accepted) as de facto. At the end of the day though, Fat is the guy who has to deal with all the tickets talking about 'This doesn't compile in jsmin', and I'd think his life would ultimately be better off if he just added a semi-colon. Of course, that's my opinion only, so take it for what it's worth.

enneff 15y ago

That doesn't sound right to me. Making s language's syntax more liberal is not a sane way to correct errors. If anything, JavaScript's ASI is an error creation mechanism.

magicalist 15y ago
Yes, he's acknowledged many times (including in this post) that it was a mistake. That was the intention, but it wasn't successful. It should have gone all in (no semicolons at all) or not have existed.
- tolmasky 15y ago
  I think it was a reasonable decision at the time. The idea was that JavaScript was not going to be some language people wrote hundreds of thousands of lines of code in, and that the target audience would become frustrated if the language didn't "help" them. For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error: <a onClick = "someFunc()" > ... > Error, missing semicolon after ")" on line 1 That could get pretty annoying pretty fast, and simple little event handlers like these were probably the main use of JavaScript for the first x years. It also matched the existing philosophy of HTML which was to really go out of its way to make sense of whatever was in the file. Now of course, the constraints are different: people want to use JavaScript for huge codebases and serious projects, so it makes sense that these decisions are no longer appropriate.
  - masklinn 15y ago
    > For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error: Depends whether the semicolon is defined as a terminator or as a separator. This would be valid code with statement separator semicolons.
  - deleted 15y ago
    [deleted]
  - geoffschmidt 15y ago
    Couldn't the 'onClick' case have been solved by allowing either a statement or an expression to appear there?
raganwald 15y ago
"Here is your new apartment. You must use a key to enter it. If you forget your key, you can buzz the superintendent during business hours, and if the super is home, (s)he will open the door for you.” If you try to take your key with you at all times, the super will save your bacon once in a blue moon when you forget your key. On the other hand, if you think of the door as only needing a key when you wish to have it opened on nights and week-ends, you are on your way to trouble.
- ronaldj 15y ago
  That's a great analogy.
  - groovy2shoes 15y ago
    The difference is that if you forget your key, you know that you forgot your key, and you have to actively call the superintendent to have them "save your bacon." With ASI, you might never know that you had forgotten your key.
    - eli 15y ago
      I agree that it would be nice to have something like "-Wall" that could warn you that you're doing things the "wrong way" but, uh, isn't that what JSLint is?
      - deleted 15y ago
        [deleted]
  - jerf 15y ago
    That's a terrible analogy. What's the analog for receiving a syntax error instead when you "forget your keys"? The analogy gives you bizarre and wrong choices and tradeoffs. As usual, analogies do more harm than good, especially when understanding a relatively simple technical issue.
    - 15y ago
spohlenz 15y ago
I believe he refers to error correction as in it corrects errors in the code -- i.e. the code itself should have semicolons and is fixed through ASI.
- BrendanEich 15y ago
  Right. To avoid confusion, I updated the post so the sentence reads "ASI is (formally speaking) a syntactic error correction procedure."
  - _delirium 15y ago
    Given that these are all formal languages, though, isn't that equivalent to saying that ASI is, formally speaking, part of the language's syntax? It's all just parsers! Apart from the social conventions around them, of course.
    - BrendanEich 15y ago
      No, there's an important distinction. ASI does not even kick in without a syntax error. Yet the "expectation of ASI" or (I think more likely) "expectation of newline significance" makes people believe that they'll get a ; inserted by separating two things by one or more newlines. Most languages do not specify error correction. HTML5 of course does; CSS too; among general programming languages it's much less common. The spec for ASI does not fit in the tried-and-true LR(1) formalism used by ECMA-262. Parsing is not all ad-hoc or equally well-formalized and proven. In addition to ASI, ECMA-262 has to use lookahead restrictions and a bit of semantic checking to cope with what could be purely syntactic concerns (say, if it could use GLR instead of LR(1)).
      - _delirium 15y ago
        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.

chad_walters 15y ago

It's interesting because the 5.1 specification doesn't say it is an error correction mechanism, it states: "For convenience, however, such semicolons may be omitted from the source text in certain situations".

bmelton 15y ago

I think the other thing that goes unmentioned is that a single semi-colon on a line in a file would pretty much end this debate. Perhaps I've worked too much in teams, but surely "path of least resistance" has to factor some, right? I mean, if the choice is add a semi-colon to a line in a file versus asking somebody else to rewrite the compiler to be able to accept it, surely common sense would just be to add the semi-colon. It doesn't mean that you're wrong, or that your code is broken, or that Crockford is smarter than you... but now you have code that works and compiles and that people can use. Surely, that's gotta count for something, right?

anonymoushn 15y ago
Even if we inserted the semicolon, JSMin would still be broken :)
tomjen3 15y ago
No. Sure it is the easier solution right now. But in the long run that would mean the Crockford would be able to dictate the style of Javascript to whatever the hell he wants. Given how important Javascript is now (and will be in the future) we cannot allow any one person to retard the entire future. Anyway use Googles closure compiler -- it can actually handle Javascript.
- bmelton 15y ago
  I think that's a visceral reaction based on his rudeness. So long as he keeps building tools and utilities that people rely on, and that people use, he is at least influencing the direction of Javascript and, knowing that, I'd think one might take heed when Crockford says "this will break in the future", as he happens to have more insight into the language than most. I understand that he wasn't polite, and I certainly understand the desire for the 'asshole' to be proven wrong. And maybe he is. Of course, that doesn't make him wrong, and it doesn't mean that he's "retarding the future" either, necessarily. But the fact that jsmin is perhaps the most widely deployed JS minification utility does matter, whether anyone chooses to accept it or not. And if you really think that he is retarding the future, the correct answer probably isn't to bicker about it on the internet, but to create a better compiler (or work on getting a better compiler accepted) as de facto. At the end of the day though, Fat is the guy who has to deal with all the tickets talking about 'This doesn't compile in jsmin', and I'd think his life would ultimately be better off if he just added a semi-colon. Of course, that's my opinion only, so take it for what it's worth.