Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <4191624.W6QT1uhmCP@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Wed, 29 Aug 2012 22:20:21 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 114 NNTP-Posting-Date: 29 Aug 2012 22:20:23 CEST NNTP-Posting-Host: 954713fe.newsspool3.arcor-online.net X-Trace: DXC== On 8/29/2012 1:56 AM, RobG wrote: >> The syntax for the do..while statement (ECMA-262 12.6.1[1]) is: >> >> do /Statement/ while ( /Expression/ ); >> >> Noting the trailing semicolon, I expected the following to throw an >> error: >> >> do {} while (false) var x = 3; >> >> since there is no semicolon to separate the two statements. However, >> I've tested a number of browsers and no error is thrown. So either the >> browsers I tested are all tolerant of the error (possible in one or >> two but unlikely in half a dozen) or automatic semicolon insertion is >> at work. > > maybe?... (speculation here, based partly on my own implementation). Did you mean _interpretation_? If not, your implementation is borken. > because some implementations don't actually "insert" semicolons, rather > they "eat" them (check for semicolon, and if-seen, it is discarded). > (this would be because it is faster and easier to treat the semicolon as > a break and then eat it, than it is to figure out how to write logic to > accurately figure out where to insert them, the "semicolon insertion" > may then be generally interpreted as "if we may see a semicolon here, > and see a newline or similar instead, interpret it as if it were a > semicolon"). > > but, upon trying to eat the semicolon, there is none there for it to > eat, so it continues on as normal (and since the do/while statement is > otherwise self-terminating, it does not lead to an ambiguity). I realize that you said "maybe?" and "speculation", but still… Utter nonsense. What actually happens is very simple: ,-[ECMA-262, 5.1 Edition] | | 7.9 Automatic Semicolon Insertion | | Certain ECMAScript statements (empty statement, variable statement, | expression statement, do-while statement, continue statement, break | statement, return statement, and throw statement) must be terminated with | semicolons. Such semicolons may always appear explicitly in the source ^^^ ^^^^^^^^^^^^^^^^^ | text. For convenience, however, such semicolons may be omitted from the ^^^^^^^^^^^^^^ | source text in certain situations. These situations are described by | saying that semicolons are automatically inserted into the source code ^^^^^^^^^^^^^^^^^^^^^^^^^^ (MUST) | token stream in those situations. ^^^^^^^^^^^^^^^^^^^ IOW, do {} while (false) var x = 3; *is* equivalent to do {} while (false); var x = 3; because `var' delimits a /VariableStatement/ and the parser is allowed, in order to produce /Program/ → /SourceElements_opt/ → /SourceElements/ /SourceElement/ → /SourceElement/ /SourceElement/ → /Statement/ /Statement/ → /IterationStatement/ /VariableStatement/ → do /Statement/ while ( /Expression/ ); /VariableStatement/ → do /Block/ while ( /Expression/ ); /VariableStatement/ → … → do {} while ( true ); var x = 3; to insert the semicolon before the /VariableStatement/. It's not a bug, it's a feature, and a standards-compliant feature at that. >> But my understanding of automatic semicolon insertion (ECMA-262 >> 7.9[2]) doesn't cover this case. >> >> Can someone please explain why no error is thrown and it seems that a >> semicolon is inserted? >> >> >> 1. http://es5.github.com/#x12.6.1 >> 2. http://es5.github.com/#x7.9 >> > > standards are not always interpreted as an exact definition of the > mechanisms, rather, of their externally perceived interface and behavior. > > in edge cases though, one may find things where the behavior of actual > implementations differs in minor ways from the mechanism which may be > implied by the wording of a standard (though usually implementations > will usually try to avoid this where possible). Again, utter nonsense. Instead, this particular standard gives its conforming implementations a wide latitude (see "Conformance"); in addition, some of its implementations are simply not conforming in some features. See also: PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, (2004)