[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Optional semicolons - wrong rule or wrong example?

Piotrek

12/16/2014 9:59:00 PM

In the 6th edition of "JavaScript: The Definitive Guide",
in chapter 2.5 (Optional Semicolons), the following rule
can be found:

"JavaScript treats a line break as a semicolon if the next
nonspace character cannot be interpreted as a continuation of
the current statement".

and the following example is given:

var a
a
=
3
console.log(a)

According to the author, the above shall be treated as:

var a; a = 3; console.log(a);

He justifies it as follows:

"JavaScript does treat the first line break as a semicolon because it cannot parse the code var a a without a semicolon."

but I can't agree with his claim. To start with,
why does he assume these two lines:

var a
a

would be interpreted as:

"var a a" instead of "var aa"?

Where would the extra space between two characters "a" come from?
I'm not saying he's wrong, but the rule says nothing about it.

Let's quote it once again and try to apply to our example,
step by step:

"JavaScript treats a line break as a semicolon if the next
nonspace character cannot be interpreted as a continuation of
the current statement".

What we have in our example is: "var a" followed by a line break,
then a nonspace character ("a") followed by a line break,
another nonspace character ("=") followed by a line break
and one more nonspace character ("3"), the remaining
part is irrelevant.

I see no reason why those three nonspace characters following "var a"
cannot be interpreted as a continuation of it. Which part of
the rule would it violate to concatenate them with the current statement
("var a") to form "var aa=3"? Nothing in the rule seems to force
an implicit semicolon right after "var a".

To make a long story short, why is the discussed example
supposed to be interpreted as:

var a; a = 3; console.log(a);

instead of:

var aa = 3; console.log(a); ?

It looks like either the rule is wrong/incomplete or the example
is wrong. Can you please give the correct rule for optional
semicolons and apply it to my example, step by step?





22 Answers

Christoph M. Becker

12/16/2014 10:21:00 PM

0

Peter wrote:

> In the 6th edition of "JavaScript: The Definitive Guide", in chapter
> 2.5 (Optional Semicolons), the following rule can be found:
>
> "JavaScript treats a line break as a semicolon if the next nonspace
> character cannot be interpreted as a continuation of the current
> statement".
>
> and the following example is given:
>
> var a a = 3 console.log(a)
>
> According to the author, the above shall be treated as:
>
> var a; a = 3; console.log(a);
>
> He justifies it as follows:
>
> "JavaScript does treat the first line break as a semicolon because it
> cannot parse the code var a a without a semicolon.">

The ECMAScript specification, edition 5.1, explains the rule more
clearly[1]:

| When, as the program is parsed from left to right, a token (called
| the offending token) is encountered that is not allowed by any
| production of the grammar, then a semicolon is automatically inserted
| before the offending token if one or more of the following conditions
| is true:
| * The offending token is separated from the previous token by at
| least one LineTerminator.
| * The offending token is }.

Obviously, it is important to clearly distinguish between *tokens* and
*characters* for this rule.

<http://www.ecma-international.org/ecma-262/5.1/#sec...

--
Christoph M. Becker

Thomas 'PointedEars' Lahn

12/16/2014 11:11:00 PM

0

Peter wrote:
^^^^^
This is Usenet; welcome. Please append your last name, Peter #74656.
And avoid the buggy Google Groups interface if you can.

> In the 6th edition of "JavaScript: The Definitive Guide",
> in chapter 2.5 (Optional Semicolons), the following rule
> can be found:
>
> "JavaScript treats a line break as a semicolon if the next
> nonspace character cannot be interpreted as a continuation of
> the current statement".
>
> and the following example is given:
>
> var a
> a
> =
> 3
> console.log(a)
>
> According to the author, the above shall be treated as:
>
> var a; a = 3; console.log(a);

It is.

> He justifies it as follows:
>
> "JavaScript does treat the first line break as a semicolon because it
> cannot parse the code var a a without a semicolon."

Correct, but imprecise.

> but I can't agree with his claim. To start with,
> why does he assume these two lines:
>
> var a
> a
>
> would be interpreted as:
>
> "var a a" instead of "var aa"?

Common sense already dictates that. The newline is a separator; one must
assume it has meaning. Simply ignoring the separator would change the
meaning of the source code, which is not a good idea.

> Where would the extra space between two characters "a" come from?

Newline, see above.

> I'm not saying he's wrong, but the rule says nothing about it.

He is wrong on several other things, though. Take this book with a handful
of salt. It is only referred by the FAQ as the best of the bad ones (in the
opinion of some, excluding me), and none have been recommended as "good" to
date.

> Let's quote it once again and try to apply to our example,
> step by step:
>
> "JavaScript treats a line break as a semicolon if the next
> nonspace character cannot be interpreted as a continuation of
> the current statement".

First of all, know that the author of that book does not have a clue what
JavaScript is. Somewhat of a result, neither do you â?? yet.

He is writing â??JavaScriptâ??, but he is actually describing several ECMAScript
implementations in Web browsers which may or may not have all of the
described features in common, without being aware of it. He is _not_
describing several other ECMAScript implementations, and may be wrong with
regard to the common features of those that he thinks he is describing, in
Web browsers and elsewhere, being blissfully unaware of it. Somewhat of a
result, so were you â?? until now.

> I see no reason why those three nonspace characters following "var a"

If you think about it a bit more, there are more than three of them.

> cannot be interpreted as a continuation of it. Which part of
> the rule would it violate to concatenate them with the current statement
> ("var a") to form "var aa=3"?

Nothing; see the bottom of this posting for an explanation.

> Nothing in the rule seems to force an implicit semicolon right after "var
> a".

Correct. The claimed rule is wrong.

> To make a long story short, why is the discussed example
> supposed to be interpreted as:
>
> var a; a = 3; console.log(a);
>
> instead of:
>
> var aa = 3; console.log(a); ?

Let us assume that common sense is applied and the newline is parsed as if
it was a space character. This leaves us with

var a a

Now, the rule(s) that dictate(s) that this must be parsed as

var a; a

instead when the separator *was* a newline, can be found in the
ECMAScript(!) Language Specification and its grammar (the HTML rendering of
it is referred here; see the top of the document for the definitive [PDF]
version):

,-<http://ecma-international.org/ecma-262/5.1/#se...
|
| VariableStatement :
| var VariableDeclarationList ;
|
| VariableDeclarationList :
| VariableDeclaration
| VariableDeclarationList , VariableDeclaration
|
| VariableDeclarationListNoIn :
| VariableDeclarationNoIn
| VariableDeclarationListNoIn , VariableDeclarationNoIn
|
| VariableDeclaration :
| Identifier Initialiser_opt
|
| VariableDeclarationNoIn : Identifier InitialiserNoIn_opt
|
| Initialiser : = AssignmentExpression
|
| InitialiserNoIn : = AssignmentExpressionNoIn

Because of the â??varâ? keyword, the VariableStatement production is to be
applied. The second â??aâ? cannot be produced by the Initialiser or
InitialiserNoIn production. As a result, a syntactical correct statement
can only be produced by

VariableStatement
â?? "var" VariableDeclarationList ";"
â?? "var" VariableDeclaration ";"
â?? "var" Identifier Initialiser_opt ";"
â?? "var" Identifier ";"
â?? "var" "a" ";"
â?? "var a;"

So the semicolon is inserted after â??var aâ?.

The same reasoning, based on different rules of the grammar, can be applied
to the other two instances.

(For clarity, I have exchanged the usual /Goal/ markup for marking up
"Literals" instead.)

> It looks like either the rule is wrong/incomplete or the example
> is wrong.

The claimed rule is wrong because of oversimplification. You can find such
often in such books, particularly in those that contain â??definitiveâ? in
their title.

> Can you please give the correct rule for optional semicolons

<http://ecma-international.org/ecma-262/5.1/#s..., rule 1.

> and apply it to my example, step by step?

[x] done

Next time, do not ask a Yes-or-No question unless you want a Yes-or-No
answer.

<http://www.catb.org/~esr/faqs/smart-question...

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Christoph M. Becker

12/17/2014 12:30:00 AM

0

Thomas 'PointedEars' Lahn wrote:

> He is writing â??JavaScriptâ??, but he is actually describing several ECMAScript
> implementations in Web browsers which may or may not have all of the
> described features in common, without being aware of it.

Flanagan explains his use of the term "JavaScript" in a box in the
introduction chapter of the 6th edition[1]:

| [...] In practice, just about everyone calls the language JavaScript.
| This book uses the name "ECMAScript" only to refer to the language
| standard.

One may argue that this is awkward, but at least he informs the reader
about his chosen nomenclature.

> He is _not_
> describing several other ECMAScript implementations, and may be wrong with
> regard to the common features of those that he thinks he is describing, in
> Web browsers and elsewhere, being blissfully unaware of it. Somewhat of a
> result, so were you â?? until now.

Indeed, it seems that the current (6th) edition does not even mention
the availability and usage of ECMAScript implementations other than in
Web browsers, what renders the title of the book deficient. Other than
that, it is to my knowledge the best available textbook on practical
browser side scripting. Taken with a grain of salt, I consider it a
decent *introduction* to this subject.

[1] This part of the book is (currently) available online via the book
preview ("Look inside") on amazon:
<http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides-ebook/dp/B004XQX4K0/ref=sr_1_1...

--
Christoph M. Becker

Erwin Moller

12/18/2014 1:40:00 PM

0

On 12/16/2014 10:58 PM, Peter wrote:
> In the 6th edition of "JavaScript: The Definitive Guide",
> in chapter 2.5 (Optional Semicolons), the following rule
> can be found:
>
> "JavaScript treats a line break as a semicolon if the next
> nonspace character cannot be interpreted as a continuation of
> the current statement".
>
> and the following example is given:
>
> var a
> a
> =
> 3
> console.log(a)
>
> According to the author, the above shall be treated as:
>
> var a; a = 3; console.log(a);
>
> He justifies it as follows:
>
> "JavaScript does treat the first line break as a semicolon because it cannot parse the code var a a without a semicolon."
>

My advice:
When things are confusing, strive to make them clear.
Don't rely on (poorly understood) rules to solve the problem.
Simply avoid the problem.

In this case: Simply stick to using a semicolon, even if you are allowed
to omit it.


This case reminds me of order of operations: (multiply, power, addition,
division, modulo, etc)
http://en.wikipedia.org/wiki/Order_of_operations#Programming...

I don't know that list by heart, so I use parenthesis a lot to make the
order clear.

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

Tim Streater

12/18/2014 2:04:00 PM

0

In article <5492d90d$0$2851$e4fe514c@news2.news.xs4all.nl>, Erwin
Moller <erwinmollerusenet@xs4all.nl> wrote:

>My advice:
>When things are confusing, strive to make them clear.
>Don't rely on (poorly understood) rules to solve the problem.
>Simply avoid the problem.
>
>In this case: Simply stick to using a semicolon, even if you are allowed
>to omit it.
>
>This case reminds me of order of operations: (multiply, power, addition,
>division, modulo, etc)
>http://en.wikipedia.org/wiki/Order_of_operations#Programming...
>
>I don't know that list by heart, so I use parenthesis a lot to make the
>order clear.

This is very good advice.

--
"If you're not able to ask questions and deal with the answers without feeling
that someone has called your intelligence or competence into question, don't
ask questions on Usenet where the answers won't be carefully tailored to avoid
tripping your hair-trigger insecurities." - D M Procida, UCSM

Thomas 'PointedEars' Lahn

12/20/2014 10:00:00 PM

0

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> He is writing â??JavaScriptâ??, but he is actually describing several
>> ECMAScript implementations in Web browsers which may or may not have all
>> of the described features in common, without being aware of it.
>
> Flanagan explains his use of the term "JavaScript" in a box in the
> introduction chapter of the 6th edition[1]:
>
> | [...] In practice, just about everyone calls the language JavaScript.
> | This book uses the name "ECMAScript" only to refer to the language
> | standard.
>
> One may argue that this is awkward, but at least he informs the reader
> about his chosen nomenclature.

But it is not well-defined (â??the languageâ?), so whatever statement he makes
using it is most certainly wrong. If so, it will be only subtly wrong,
therefore misleading to the beginner who must acquire the misconception that
they are dealing with only one programming language.

>> He is _not_ describing several other ECMAScript implementations, and may
>> be wrong with regard to the common features of those that he thinks he is
>> describing, in Web browsers and elsewhere, being blissfully unaware of
>> it. Somewhat of a result, so were you â?? until now.
>
> Indeed, it seems that the current (6th) edition does not even mention
> the availability and usage of ECMAScript implementations other than in
> Web browsers, what renders the title of the book deficient. Other than
> that, it is to my knowledge the best available textbook on practical
> browser side scripting. Taken with a grain of salt, I consider it a
> decent *introduction* to this subject.

A *grain*?

> [1] This part of the book is (currently) available online via the book
> preview ("Look inside") on amazon:
> <http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides-ebook/dp/B004XQX4K0/ref=sr_1_1...

I do not have time for a full review, but if I had to pick three instances
as to why it should be avoided, it would be these:

The Introduction
-----------------

His entire description of â??Client-side JavaScriptâ? is hopelessly outdated.
Host objects have not been part of any implementation since more than a
decade ago, and then only one, Netscape JavaScript (up to version 1.3).

Operators
----------

The chapter on operators (chapter 4?) that has been random-access reviewed
by Douglas Cornford before is *still* wrong. â??Member accessâ? should be
â??property accessâ?, and is _not_ an operator. Calling a function (as a
function) is _not_ an operation. The term â??operator precedenceâ? simply does
not apply to several syntactical constructs listed there. The only
improvement that I can see is that the â??Array operatorâ? is no longer there;
it has been replaced by â??member accessâ?. But that chapter is incomplete in
the preview.

Inheritance
------------

There are neither classes nor modules in implementations of ECMAScript
Edition 5, yet there is an entire chapter â??Classes and Modulesâ? and a
section â??Classes in ECMAScript 5â?. One can read subsection titles like
â??Defining a Subclassâ?.

In that line of thought, there is an important difference between Date.now()
and Date.prototype.setDate() [the latter is implicitly inherited, the former
is not], but he writes the latter â??Date.setDate()â? (like many other people
who are ignorant of prototype-based inheritance).

I can not only not recommend this bug^H^Hook, but I have to *strongly*
recommended against it. (Like all previous editions of it.)

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

12/20/2014 10:05:00 PM

0

Thomas 'PointedEars' Lahn wrote:

> The chapter on operators (chapter 4?) that has been random-access reviewed
> by Douglas Cornford before is *still* wrong.

Sorry, _Richard_ Cornford (I confused him with Douglas Crockford, another
previous regular here).

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Christoph M. Becker

12/28/2014 10:53:00 PM

0

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
>
>> Taken with a grain of salt, I consider it a
>> decent *introduction* to this subject.
>
> A *grain*?

Is there any definition regarding the maximum size of a grain? ;)

>> [1] This part of the book is (currently) available online via the book
>> preview ("Look inside") on amazon:
>> <http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides-ebook/dp/B004XQX4K0/ref=sr_1_1...
>
> I do not have time for a full review, but if I had to pick three instances
> as to why it should be avoided, it would be these:
>
> The Introduction
> -----------------
>
> His entire description of â??Client-side JavaScriptâ? is hopelessly outdated.
> Host objects have not been part of any implementation since more than a
> decade ago, and then only one, Netscape JavaScript (up to version 1.3).

At least Flanagan has separate parts for "Core JavaScript" and
"Client-Side JavaScript".

> Operators
> ----------
>
> The chapter on operators (chapter 4?) that has been random-access reviewed
> by Douglas Cornford before is *still* wrong. â??Member accessâ? should be
> â??property accessâ?, and is _not_ an operator. Calling a function (as a
> function) is _not_ an operation. The term â??operator precedenceâ? simply does
> not apply to several syntactical constructs listed there. The only
> improvement that I can see is that the â??Array operatorâ? is no longer there;
> it has been replaced by â??member accessâ?. But that chapter is incomplete in
> the preview.

Indeed. Chapter 4 is titled "Expressions and Operators", and you are
probably referring to table 4-1 which is placed immediately before the
section heading "Operator Overview". This table is labelled "JavaScript
expressions", and interestingly, it is not contained in my ebook copy of
the 6th edition. Anyway, what is called "(Computed) member access" in
this table is called "Property Access Expressions" a few sections before.

> Inheritance
> ------------
>
> There are neither classes nor modules in implementations of ECMAScript
> Edition 5, yet there is an entire chapter â??Classes and Modulesâ? and a
> section â??Classes in ECMAScript 5â?. One can read subsection titles like
> â??Defining a Subclassâ?.

Quite a the beginning of this chapter Flanagan writes:

| It is often useful, however, to define a /class/ of objects that
| share certain properties.

IMHO that is not wrong, and hints that his use of the term is rather
abstract. The next paragraph, however, starts with:

| In JavaScript, classes are based on JavaScript's prototype-based
| inheritance mechanism.

That's a rather sloppy formulation, at best.

> I can not only not recommend this bug^H^Hook, but I have to *strongly*
> recommended against it. (Like all previous editions of it.)

Well, but what are the alternatives when one is looking for a
comprehensive introduction to browser side scripting in ECMAScript
implementations? AFAIK many other sources are (much) worse.

Requiring a *beginner* to wade through the ECMAScript specification, the
W3C standards regarding the DOM and other relevant APIs and the
documentation of the browser vendors, seems undue.

--
Christoph M. Becker

Tim Streater

12/28/2014 11:53:00 PM

0

In article <m7q1jg$fnc$1@solani.org>, Christoph M. Becker
<cmbecker69@arcor.de> wrote:

>Thomas 'PointedEars' Lahn wrote:
>
>> Christoph M. Becker wrote:
>>
>>> Taken with a grain of salt, I consider it a
>>> decent *introduction* to this subject.
>>
>> A *grain*?
>
>Is there any definition regarding the maximum size of a grain? ;)

64.79891 milligrams, according to Winky.

--
"A committee is a cul-de-sac down which ideas are lured and then
quietly strangled." - Sir Barnett Cocks (1907-1989)

Scott Sauyet

1/2/2015 5:47:00 AM

0

Tim Streater wrote:
> Christoph M. Becker wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>
>>> Christoph M. Becker wrote:
>>>
>>>> Taken with a grain of salt, I consider it a
>>>> decent *introduction* to this subject.
>>>
>>> A *grain*?
>>
>> Is there any definition regarding the maximum size of a grain? ;)
>
> 64.79891 milligrams, according to Winky.

Coincidentally, this is, according to the same source, also the
maximum size of a grain. :-)

-- Scott