Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #15606 > unrolled thread

Re: Semicolons and the do..while statement

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Semicolons and the do..while statement BGB <cr88192@hotmail.com> - 2012-08-29 13:55 -0500
    Re: Semicolons and the do..while statement Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-29 22:20 +0200
      Re: Semicolons and the do..while statement BGB <cr88192@hotmail.com> - 2012-08-29 20:02 -0500
      Re: Semicolons and the do..while statement RobG <rgqld@iinet.net.au> - 2012-08-29 18:27 -0700
        Re: Semicolons and the do..while statement Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-30 12:37 +0200
      Re: Semicolons and the do..while statement John G Harris <john@nospam.demon.co.uk> - 2012-08-30 14:24 +0100
        Re: Semicolons and the do..while statement Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-30 15:59 +0200
          Re: Semicolons and the do..while statement John G Harris <john@nospam.demon.co.uk> - 2012-08-30 16:26 +0100
            Re: Semicolons and the do..while statement Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-30 17:47 +0200
              Re: Semicolons and the do..while statement John G Harris <john@nospam.demon.co.uk> - 2012-09-01 11:40 +0100
                Re: Semicolons and the do..while statement Dr J R Stockton <reply1235@merlyn.demon.co.uk.invalid> - 2012-09-02 19:54 +0100
            Re: Semicolons and the do..while statement BGB <cr88192@hotmail.com> - 2012-08-30 11:17 -0500
        Re: Semicolons and the do..while statement Gene Wirchenko <genew@ocis.net> - 2012-08-30 10:25 -0700
          Re: Semicolons and the do..while statement Dr J R Stockton <reply1235@merlyn.demon.co.uk.invalid> - 2012-08-31 23:20 +0100
            Re: Semicolons and the do..while statement Gene Wirchenko <genew@ocis.net> - 2012-08-31 16:03 -0700
    Re: Semicolons and the do..while statement Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-29 22:30 +0200

#15606 — Re: Semicolons and the do..while statement

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).

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).


> 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).

[toc] | [next] | [standalone]

#15607

BGB wrote:

> 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: <http://PointedEars.de/es-matrix>


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#15613

On 8/29/2012 3:20 PM, Thomas 'PointedEars' Lahn wrote:
> BGB wrote:
>
>> 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.
>

this particular implementation is in the gray area between being "not 
exactly conformant" and "an entirely different language" (it is used 
mostly for application-level scripting, currently within a 3D game engine).


>> 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.
>

actually, the implementation in question does actually work this way.

it seemed at least possible that other implementations could have worked 
in a similar way.


> 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.
>                 ^^^^^^^^^^^^^^^^^^^
>

in this case, it only behaves as if this were happening, but the actual 
logic is instead based on noticing certain patterns, and eating the tokens.

the reason was partly because this could be done directly within the 
parser logic, without needing to actually "insert" anything (there is no 
separate lexer or parser stages either, FWIW, just a single-pass 
recursive descent parser).


<snip rest>

[toc] | [prev] | [next] | [standalone]

#15614

On Aug 30, 6:20 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> BGB wrote:
> > 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.
[..]

[..]
>
> 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.
>                ^^^^^^^^^^^^^^^^^^^

Since "certain situations" are not explained (other than by the
circuitous logic that they're those where semicolons are inserted), I
understood that section as a preamble to 7.9.1 which sets out a number
of "certain situations" and 3 rules for insertion. It is those 3 rules
that don't cover the do..while case I posted, they seem to require
either a new line or that a '}' is involved in order to insert a
semicolon.

e.g.  7.9.1 #1 covers the following cases:

    var x = 3
    var y = 4

A semicolon is inserted after the first line because it's followed by
a newline character and then something that can't be part of the
variable declaration statement.

    (function(){alert('hi')})
--------------------------^

The missing semicolon indicated is inserted because the following
character is '}' and a semicolon is inserted at the end because it's
the end of the input stream.

> 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.

I suppose I'm still missing something because my understanding of this
explanation is that a semicolon should be inserted for

     /VariableStatement/ /VariableStatement/

as it's one of the "certain statements", but it isn't. If the newline
is removed from the variable statement example above:

    var x = 3 var y = 4

then a syntax error is thrown. I can't see how the second "var" can be
interpreted as anything other than the start of a variable statement,
and therefore that a semicolon can (or should) be inserted before it
(per your logic above).

The only explanation I can think of is that the "v" at the start of
the second "var" is interpreted as the start of an identifier, so
either a semicolon, comma[1] or newline (which would force semicolon
insertion) is required. Because of the ambiguity, an error results, so
the whole "var" token is not read and the second variable statement
isn't identified.

1. Allowing for the fact that if a comma is inserted, it only gets one
step further because the var keyword can only appear at the start of a
variable declaration statement.


Regarding references, I use the Github version of ES5 because it also
links to other resources and has some handy features that aren't
available in the ECMA version. As far as I know, the text is unaltered
from the official version.


--
Rob

[toc] | [prev] | [next] | [standalone]

#15615

RobG wrote:

> Thomas 'PointedEars' Lahn wrote:
> 
> [breakdown of ASI]

That appears to be correct.

>> 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/.

To be precise, after the closing parenthesis of a supposed do-while 
statement.  Function serialization, although implementation-dependent, can 
show this:

$ js
Rhino 1.7 release 2 2010 02 06
js> (function () { do {} while (true) var x = 3; }).toString()

function () {
    do {
    } while (true);
    var x = 3;
}

>> It's not a bug,>it's a feature, and a standards-compliant feature at
>> that.
> 
> I suppose I'm still missing something because my understanding of this
> explanation is that a semicolon should be inserted for
> 
>      /VariableStatement/ /VariableStatement/
> 
> as it's one of the "certain statements", but it isn't. If the newline
> is removed from the variable statement example above:
> 
>     var x = 3 var y = 4
> 
> then a syntax error is thrown.

ACK:

js> (function () { var x = 3 var y = 4; }).toString()
js: "<stdin>", line 3: missing ; before statement
js: (function () { var x = 3 var y = 4; }).toString()
js: ............................^

> I can't see how the second "var" can be interpreted as anything other than
> the start of a variable statement, and therefore that a semicolon can (or
> should) be inserted before it (per your logic above).

Good "question".  I do not have a good answer to it yet.  However:
 
> The only explanation I can think of is that the "v" at the start of
> the second "var" is interpreted as the start of an identifier, so
> either a semicolon, comma[1] or newline (which would force semicolon
> insertion) is required. Because of the ambiguity, an error results, so
> the whole "var" token is not read and the second variable statement
> isn't identified.

I think we can exclude that possibility.  `var' is a /ReservedWord/, in 
particular a /Keyword/, so explicitly _not_ an /Identifier/:

| 7.6.1 Reserved Words
| 
| A reserved word is an IdentifierName that cannot be used as an Identifier.
| 
| Syntax
| 
| ReservedWord ::
|   Keyword
|   FutureReservedWord
|   NullLiteral
|   BooleanLiteral
| 
| 7.6.1.1 Keywords
| 
| The following tokens are ECMAScript keywords and may not be used as
| Identifiers in ECMAScript programs.
| 
| Syntax
| 
| Keyword :: one of
|   break     do        instanceof  typeof
|   case      else      new         var
|   catch     finally   return      void
|   continue  for       switch      while
|   debugger  function  this        with
|   default   if        throw       delete
|   in        try


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#15618

On Wed, 29 Aug 2012 at 22:20:21, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

  <snip>
>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
>
  ...
>
>to insert the semicolon before the /VariableStatement/.  It's not a bug,
>it's a feature, and a standards-compliant feature at that.
  <snip>

This is not true. If you read ECMA 262 section 7.9.1 you will see that
the gap between  (false)  and  var  does not match *any* of the
situations where a semicolon can be inserted. The lack of a semicolon is
therefore a syntax error.

Compilers that 'correct' programming errors are not being helpful. It
can take a long time to track down an obscure bug caused by the compiler
guessing wrong.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#15619

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>   <snip>
>>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
>>
>   ...
>>
>>to insert the semicolon before the /VariableStatement/.  It's not a bug,
>>it's a feature, and a standards-compliant feature at that.
>   <snip>
> 
> This is not true. If you read ECMA 262 section 7.9.1 you will see that
> the gap between  (false)  and  var  does not match *any* of the
> situations where a semicolon can be inserted. The lack of a semicolon is
> therefore a syntax error.
> 
> Compilers that 'correct' programming errors are not being helpful. It
> can take a long time to track down an obscure bug caused by the compiler
> guessing wrong.

For crying out loud…

| 2 Conformance
| 
| […]
| A conforming implementation of ECMAScript is permitted to support program
| and regular expression syntax not described in this specification.  […]

This, if nothing else, is sufficient to make it standards-compliant.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#15620

On Thu, 30 Aug 2012 at 15:59:43, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

  <snip>
>For crying out loud…
>
>| 2 Conformance
>|
>| […]
>| A conforming implementation of ECMAScript is permitted to support program
>| and regular expression syntax not described in this specification.  […]
>
>This, if nothing else, is sufficient to make it standards-compliant.

For crying out loud, it's still a syntax error!

Unless, of course, you have made it clear you are talking about the
syntax spec for the browser, if, of course, the browser maker has
published one that shows this feature, which it hasn't.

If you'd said it's a permitted browser deviation we would have agreed,
and then pointed out that it's a bloody stupid deviation.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#15621

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> For crying out loud…
>>
>>| 2 Conformance
>>|
>>| […]
>>| A conforming implementation of ECMAScript is permitted to support
>>| program
>>| and regular expression syntax not described in this specification.  […]
>>
>> This, if nothing else, is sufficient to make it standards-compliant.
> 
> For crying out loud, it's still a syntax error!

No, it would be "program […] syntax not described in this specification".

> Unless, of course, you have made it clear you are talking about the
> syntax spec for the browser, if, of course, the browser maker has
> published one that shows this feature, which it hasn't.
> 
> If you'd said it's a permitted browser deviation we would have agreed,
> and then pointed out that it's a bloody stupid deviation.

You have no clue what you are talking about.  Troll elsewhere.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#15654

On Thu, 30 Aug 2012 at 17:47:46, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> For crying out loud…
>>>
>>>| 2 Conformance
>>>|
>>>| […]
>>>| A conforming implementation of ECMAScript is permitted to support
>>>| program
>>>| and regular expression syntax not described in this specification.  […]
>>>
>>> This, if nothing else, is sufficient to make it standards-compliant.
>>
>> For crying out loud, it's still a syntax error!
>
>No, it would be "program […] syntax not described in this specification".

Which is another way of saying "it's a permitted browser deviation" from
the standard.


>> Unless, of course, you have made it clear you are talking about the
>> syntax spec for the browser, if, of course, the browser maker has
>> published one that shows this feature, which it hasn't.
>>
>> If you'd said it's a permitted browser deviation we would have agreed,
>> and then pointed out that it's a bloody stupid deviation.
>
>You have no clue what you are talking about.  Troll elsewhere.

Hurling abuse at everyone who disagrees with you is not the most
convincing way to conduct an argument.


  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#15658

In comp.lang.javascript message <pUtdvpEWYeQQFwf6@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Sat, 1 Sep 2012 11:40:22, John G Harris
<john@nospam.demon.co.uk> posted:

>
>Hurling abuse at everyone who disagrees with you is not the most
>convincing way to conduct an argument.

If you visit Regent's Park, I think you will find that the method is
favoured by /Pan troglodytes/, but perhaps not by /Pan paniscus/.

-- 
 (c) John Stockton, nr London, UK.  For Mail, see Home Page.  Turnpike, WinXP.
 Web  <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
 Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
 DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[toc] | [prev] | [next] | [standalone]

#15622

On 8/30/2012 10:26 AM, John G Harris wrote:
> On Thu, 30 Aug 2012 at 15:59:43, in comp.lang.javascript, Thomas
> 'PointedEars' Lahn wrote:
>
>    <snip>
>> For crying out loud…
>>
>> | 2 Conformance
>> |
>> | […]
>> | A conforming implementation of ECMAScript is permitted to support program
>> | and regular expression syntax not described in this specification.  […]
>>
>> This, if nothing else, is sufficient to make it standards-compliant.
>
> For crying out loud, it's still a syntax error!
>
> Unless, of course, you have made it clear you are talking about the
> syntax spec for the browser, if, of course, the browser maker has
> published one that shows this feature, which it hasn't.
>
> If you'd said it's a permitted browser deviation we would have agreed,
> and then pointed out that it's a bloody stupid deviation.
>

my original point could be restated another way:
is it at least possible that people could have implemented their parsers 
in ways where they didn't notice that the semicolon was missing?...


digging through the V8 source (blarg, the code is hard to read) 
apparently it is an explicit feature. they eat the semicolon in this 
case, and then have a big comment to justify doing so (although for 
whatever reason they use the word "consume" rather than "eat", but 
either way...).

similarly, their logic for "ExpectSemicolon()" is very similar to what I 
call "EatSemicolon()".

IOW: no semicolon is (actually) inserted into the token-stream, rather 
the parser merely behaves as-if the semicolon were present (if it sees a 
linebreak or similar instead).

reference, in V8 code (at least for the version I have at-hand, dated 
2011-03-03):
v8/src/parser.cc:3775

and for the explicit do/while case:
v8/src/parser.cc:2191


checking:
Mozilla apparently also uses the same basic strategy as well:
for function "MatchOrInsertSemicolon()"
mozilla-central/js/src/jsparse.cpp:2020


this seems like irony.

the "insert" seems more symbolic in this case.


or such...

[toc] | [prev] | [next] | [standalone]

#15623

On Thu, 30 Aug 2012 14:24:57 +0100, John G Harris
<john@nospam.demon.co.uk> wrote:

[snip]

>Compilers that 'correct' programming errors are not being helpful. It

     ...unless the compiler states what the correction being done is.

>can take a long time to track down an obscure bug caused by the compiler
>guessing wrong.

     It also causes trouble when someone is learning the language.
Consistency is very very useful.

     I shot myself in the foot with some very silly errors in my early
JavaScript days.  Some of these were not caught very well by
JavaScript or by me.  (I once used Visual FoxPro line comments in a
section of code and could not figure why the code was not working. VFP
uses "&&" like JavaScript uses "//".  Egg, meet face.)

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15642

In comp.lang.javascript message <t98v38tk7cgphbcdn0tua01d87gh6ob6pt@4ax.
com>, Thu, 30 Aug 2012 10:25:45, Gene Wirchenko <genew@ocis.net> posted:

>
>     I shot myself in the foot with some very silly errors in my early
>JavaScript days.  Some of these were not caught very well by
>JavaScript or by me.  (I once used Visual FoxPro line comments in a
>section of code and could not figure why the code was not working. VFP
>uses "&&" like JavaScript uses "//".  Egg, meet face.)


Reminds me of a problem a colleague had on an HP "midi" computer, using
FORTRAN but with a screen editor rather than a card punch.

One of his long COMMON statements was not working correctly.  All of the
variables were in fact COMMONed, except one, at the end of the first
line.  He was baffled.  We were baffled.  It looked fine on the screen.

Then I noticed that the offending variable and its comma were sitting
neatly in columns 73 to 80.

Perhaps you remember 80-column FORTRAN cards, and what is printed on
them?  I keep one on my physical desktop for reference on occasions like
this.

-- 
 (c) John Stockton, nr London UK.  ?@merlyn.demon.co.uk  DOS 3.3 6.20 ; WinXP.
   Web  <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
   PAS EXE TXT ZIP via  <http://www.merlyn.demon.co.uk/programs/00index.htm>
   My DOS  <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.

[toc] | [prev] | [next] | [standalone]

#15646

On Fri, 31 Aug 2012 23:20:09 +0100, Dr J R Stockton
<reply1235@merlyn.demon.co.uk.invalid> wrote:

[snip]

>Reminds me of a problem a colleague had on an HP "midi" computer, using
>FORTRAN but with a screen editor rather than a card punch.
>
>One of his long COMMON statements was not working correctly.  All of the
>variables were in fact COMMONed, except one, at the end of the first
>line.  He was baffled.  We were baffled.  It looked fine on the screen.
>
>Then I noticed that the offending variable and its comma were sitting
>neatly in columns 73 to 80.

     If the statement looked fine for syntax, that is the first thing
that I would look at.  I heard a lot of these stories, so I am
sensitised to the issue.

>Perhaps you remember 80-column FORTRAN cards, and what is printed on
>them?  I keep one on my physical desktop for reference on occasions like
>this.

     Quite.

     In my computing diploma program, two course had COBOL.  I was
very careful about my columns.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15608

BGB wrote:

> On 8/29/2012 1:56 AM, RobG wrote:
>>   1. http://es5.github.com/#x12.6.1
>>   2. http://es5.github.com/#x7.9

BTW, this is a *non-normative* *private*, *anonymous* (and privately 
annotated) rendering of the 5.1 Edition of ECMAScript.  It should not be 
used as reference material.

Use the official HTML rendering of the 5.1 Edition (by Allen Wirfs-Brock 
[TC39], AFAIK) instead, or the normative PDF version.  Both are linked to 
from <http://ecmascript.org/>, and indeed, from <http://es5.github.com/>
as well.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web