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

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

Optional semicolons - wrong rule or wrong example?

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

Contents

  Optional semicolons - wrong rule or wrong example? Peter <pilarp@poczta.onet.pl> - 2014-12-16 13:58 -0800
    Re: Optional semicolons - wrong rule or wrong example? "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-16 23:21 +0100
    Re: Optional semicolons - wrong rule or wrong example? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-12-17 00:10 +0100
      JavaScript: The Definitive Guide (was: Optional semicolons - wrong rule or wrong example?) "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-17 01:29 +0100
        Re: JavaScript: The Definitive Guide Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-12-20 23:00 +0100
          Re: JavaScript: The Definitive Guide Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-12-20 23:04 +0100
          Re: JavaScript: The Definitive Guide "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-28 23:52 +0100
            Re: JavaScript: The Definitive Guide Tim Streater <timstreater@greenbee.net> - 2014-12-28 23:52 +0000
              Re: JavaScript: The Definitive Guide Scott Sauyet <scott.sauyet@gmail.com> - 2015-01-01 21:46 -0800
                Re: JavaScript: The Definitive Guide "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-02 09:32 +0100
                  Re: JavaScript: The Definitive Guide Andrew Poulos <ap_prog@hotmail.com> - 2015-01-03 07:54 +1100
                    Re: JavaScript: The Definitive Guide "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-02 22:14 +0100
                      Re: JavaScript: The Definitive Guide Andrew Poulos <ap_prog@hotmail.com> - 2015-01-03 11:46 +1100
                        Re: JavaScript: The Definitive Guide "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-03 11:59 +0100
                          Re: JavaScript: The Definitive Guide Andrew Poulos <ap_prog@hotmail.com> - 2015-01-03 23:46 +1100
                            Re: JavaScript: The Definitive Guide "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-03 14:57 +0100
                              Re: JavaScript: The Definitive Guide Andrew Poulos <ap_prog@hotmail.com> - 2015-01-04 09:31 +1100
                                Re: JavaScript: The Definitive Guide "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-04 00:29 +0100
                                  Re: JavaScript: The Definitive Guide Andrew Poulos <ap_prog@hotmail.com> - 2015-01-04 20:17 +1100
                                    Re: JavaScript: The Definitive Guide "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-01-04 10:57 +0100
                      OT: Mass, weight and friction (was: JavaScript: The Definitive Guide) "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-01-03 02:52 +0100
    Re: Optional semicolons - wrong rule or wrong example? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2014-12-18 14:39 +0100
      Re: Optional semicolons - wrong rule or wrong example? Tim Streater <timstreater@greenbee.net> - 2014-12-18 14:04 +0000

Page 1 of 2  [1] 2  Next page →

#26339 — Optional semicolons - wrong rule or wrong example?

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?

[toc] | [next] | [standalone]

#26340

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

-- 
Christoph M. Becker

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

#26342

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/#sec-12.2>
|
| 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/#sec-7.9>, 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-questions.html>

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

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

#26344 — JavaScript: The Definitive Guide (was: Optional semicolons - wrong rule or wrong example?)

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

-- 
Christoph M. Becker

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

#26365 — Re: JavaScript: The Definitive Guide

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

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.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26366 — Re: JavaScript: The Definitive Guide

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.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26403 — Re: JavaScript: The Definitive Guide

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

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

#26405 — Re: JavaScript: The Definitive Guide

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)

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

#26427 — Re: JavaScript: The Definitive Guide

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 

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

#26431 — Re: JavaScript: The Definitive Guide

Scott Sauyet <scott.sauyet@gmail.com> wrote on 02 jan 2015 in 
comp.lang.javascript:

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

Taken with the above same of the above salt? 

<http://en.wikipedia.org/wiki/Grain_(unit)>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26438 — Re: JavaScript: The Definitive Guide

On 2/01/2015 7:32 PM, Evertjan. wrote:> Scott Sauyet 
<scott.sauyet@gmail.com> wrote on 02 jan 2015 in
 > comp.lang.javascript:
 >
 >>>>>> 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.  :-)
 >
 > Taken with the above same of the above salt?
 >
 > <http://en.wikipedia.org/wiki/Grain_(unit)>

Cool, so a pound of feathers *does* weigh more than a pound of gold! 
Feathers are avoirdupois and a pound contains 7,000 grains while gold is 
troy of which a pound contains 5,760 grains (though I'm not 100% sure 
that the grain are equal).

Andrew Poulos

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

#26439 — Re: JavaScript: The Definitive Guide

Andrew Poulos <ap_prog@hotmail.com> wrote on 02 jan 2015 in 
comp.lang.javascript:

> Cool, so a pound of feathers *does* weigh more than a pound of gold! 

Mass is what stuff has, "avoir du pois" in French, 
weight is its pressure against the ground.

So no, it weighs less, 
as the feathers with the same mass as the gold have more volume,
and so their upward pressure by the surrounding air has more effect.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26442 — Re: JavaScript: The Definitive Guide

On 3/01/2015 8:14 AM, Evertjan. wrote:
> Andrew Poulos <ap_prog@hotmail.com> wrote on 02 jan 2015 in
> comp.lang.javascript:
>
>> Cool, so a pound of feathers *does* weigh more than a pound of gold!
>
> Mass is what stuff has, "avoir du pois" in French,
> weight is its pressure against the ground.

El Goog translates "avoir du pois" as "having pea", and claims that 
"avoirdupois" is a system of measuring *weight*.

> So no, it weighs less,
> as the feathers with the same mass as the gold have more volume,

Seeing one would typically work out the mass using a scale (which would 
weight them) then...

> and so their upward pressure by the surrounding air has more effect.

And what if the feathers were compressed into the same size volume that 
the gold occupies, or that the gold was beaten into a sheet one atom thick?

At any rate, asserting that 7,000 is less than 5,760 is unconvincing :-)

Also, for interests sake
<http://upload.wikimedia.org/wikipedia/commons/0/0a/Comparison_of_pounds.svg>

Andrew Poulos

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

#26448 — Re: JavaScript: The Definitive Guide

Andrew Poulos <ap_prog@hotmail.com> wrote on 03 jan 2015 in 
comp.lang.javascript:

> El Goog translates "avoir du pois" as "having pea",

While French "poids" is weight and is today pronounced quite the same,
the translation is **utterly false**. 

>  and claims that "avoirdupois" is a system of measuring *weight*.
[this claim is right, 
only in the British sense, secondarily taken over by the US]

Etymologically French "poids" [weight]
comes from old French "pois",
which comes from  Latin "pensum" [="hanged thing", so "weight"]
from "pendere" [to hang].

So "avoir du pois" is old French for "having weight",
discarding the idea of the "having pea" translation.

<http://en.wiktionary.org/wiki/avoirdupois>

I like my "petits pois" hot with some butter, 
as they don't add siginificantly to my "poids",
even without having to pea/pee.

===============

"Avoir-du-poids, système impérial britannique"
<http://fr.wiktionary.org/wiki/avoirdupois>
<http://www.larousse.fr/dictionnaires/francais/avoirdupois/7144>
<http://www.cnrtl.fr/etymologie/poids>

===============

French "pois" [pea] comes from Latin "pisum" 
and that from Greek "Pison".

http://fr.wiktionary.org/wiki/pois

"fruit d'une plante légumineuse enfermé dans une cosse verte"
<http://www.cnrtl.fr/etymologie/pois>

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26451 — Re: JavaScript: The Definitive Guide

On 3/01/2015 9:59 PM, Evertjan. wrote:
> Andrew Poulos <ap_prog@hotmail.com> wrote on 03 jan 2015 in
> comp.lang.javascript:
>
>> El Goog translates "avoir du pois" as "having pea",
>
> While French "poids" is weight and is today pronounced quite the same,
> the translation is **utterly false**.
>
>>   and claims that "avoirdupois" is a system of measuring *weight*.
> [this claim is right,
> only in the British sense, secondarily taken over by the US]
>
> Etymologically French "poids" [weight]
> comes from old French "pois",
> which comes from  Latin "pensum" [="hanged thing", so "weight"]
> from "pendere" [to hang].
>
> So "avoir du pois" is old French for "having weight",
> discarding the idea of the "having pea" translation.
>
> <http://en.wiktionary.org/wiki/avoirdupois>

That page says that in old French avoir du pois means "good of weight" 
(whatever that means).

Andrew Poulos

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

#26452 — Re: JavaScript: The Definitive Guide

Andrew Poulos <ap_prog@hotmail.com> wrote on 03 jan 2015 in 
comp.lang.javascript:

>> <http://en.wiktionary.org/wiki/avoirdupois>
> 
> That page says that in old French avoir du pois means "good of weight" 
> (whatever that means).

Well, "avoir" is the infinitive present of a verb meaing "to have".

In French among many languages a certain amount of some general thing, like 
water, milk, time, mass, weight, salt, is preceded by "of the" [du/de la].
So "Give me of the salt", as "Pass me the salt" would be considered a request 
for all the salt in the world.

So, while all translations stink in the sense of explaining original concept,
perhaps translating it as "having weight" would be better, meaning "in 
weight/mass" as compared to "in volume" or "in value".

The key difference between weight and mass only became understandable by the 
genius who was born on 25 December 1642 in Woolsthorpe-by-Colsterworth, in 
another system unit that was on 4 Januari 1643. 

Explaining a different language to a monoglot is nearly impossible, it seems.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26455 — Re: JavaScript: The Definitive Guide

On 4/01/2015 12:57 AM, Evertjan. wrote:
> Andrew Poulos <ap_prog@hotmail.com> wrote on 03 jan 2015 in
> comp.lang.javascript:
>
>>> <http://en.wiktionary.org/wiki/avoirdupois>
>>
>> That page says that in old French avoir du pois means "good of weight"
>> (whatever that means).
>
> Well, "avoir" is the infinitive present of a verb meaning "to have".
>
> In French among many languages a certain amount of some general thing, like
> water, milk, time, mass, weight, salt, is preceded by "of the" [du/de la].
> So "Give me of the salt", as "Pass me the salt" would be considered a request
> for all the salt in the world.
>
> So, while all translations stink in the sense of explaining original concept,
> perhaps translating it as "having weight" would be better, meaning "in
> weight/mass" as compared to "in volume" or "in value".
>
> The key difference between weight and mass only became understandable by the
> genius who was born on 25 December 1642 in Woolsthorpe-by-Colsterworth, in
> another system unit that was on 4 Januari 1643.
>
> Explaining a different language to a monoglot is nearly impossible, it seems.

Yeah, yeah, I speak, as my name might imply, Demotic Greek (as well as 
Australian English.)

Writing "good of weight" is confusing because "good" usually means "not 
bad" whereas "goods" predominantly means "tangible property".

Andrew Poulos

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

#26456 — Re: JavaScript: The Definitive Guide

Andrew Poulos <ap_prog@hotmail.com> wrote on 03 jan 2015 in
comp.lang.javascript: 

> On 4/01/2015 12:57 AM, Evertjan. wrote:
>> Andrew Poulos <ap_prog@hotmail.com> wrote on 03 jan 2015 in
>> comp.lang.javascript:
>>
>>>> <http://en.wiktionary.org/wiki/avoirdupois>
>>>
>>> That page says that in old French avoir du pois means "good of weight"
>>> (whatever that means).
>>
>> Well, "avoir" is the infinitive present of a verb meaning "to have".
>>
>> In French among many languages a certain amount of some general thing,
>> like water, milk, time, mass, weight, salt, is preceded by "of the"
>> [du/de la]. So "Give me of the salt", as "Pass me the salt" would be
>> considered a request for all the salt in the world.
>>
>> So, while all translations stink in the sense of explaining original
>> concept, perhaps translating it as "having weight" would be better,
>> meaning "in weight/mass" as compared to "in volume" or "in value".
>>
>> The key difference between weight and mass only became understandable
>> by the genius who was born on 25 December 1642 in
>> Woolsthorpe-by-Colsterworth, in another system unit that was on 4
>> Januari 1643. 
>>
>> Explaining a different language to a monoglot is nearly impossible, it
>> seems. 
> 
> Yeah, yeah, I speak, as my name might imply, Demotic Greek (as well as 
> Australian English.)
> 
> Writing "good of weight" is confusing because "good" usually means "not 
> bad" whereas "goods" predominantly means "tangible property".

Well, Mr Andreas Pavlos, 
I still have a hang for the Katarevousa, 
and Signetics 2650 Assembler.

> Andrew Poulos

In the mean time, 
perhaps we should confine ourselves to the many dialects of Javascript.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#26457 — Re: JavaScript: The Definitive Guide

On 4/01/2015 10:29 AM, Evertjan. wrote:

> Well, Mr Andreas Pavlos,

"Pavlos" is usually translated as "Paul" which is not my name.

> I still have a hang for the Katarevousa,

Normally its written as "Katharevousa" and I know a few people who can 
read it but "its all Greek to me". My mum thinks there's been a subtle 
loss going from (to her) a more precise polytonic orthography to a 
monotonic one.

> In the mean time,
> perhaps we should confine ourselves to the many dialects of Javascript.

Ok.

Andrew Poulos

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

#26458 — Re: JavaScript: The Definitive Guide

Andrew Poulos <ap_prog@hotmail.com> wrote on 04 jan 2015 in 
comp.lang.javascript:

> On 4/01/2015 10:29 AM, Evertjan. wrote:
> 
>> Well, Mr Andreas Pavlos,
> 
> "Pavlos" is usually translated as "Paul" which is not my name.

I see, poulos, -poulos or povlos as in child or little chicken?

> "Pavlos" is usually translated as "Paul"

Wouldn't that "translation" depend on your location in the world,
just like the substrate that a JS implementation is living on?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web