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

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

What's a good Javascript book?

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

Contents

  What's a good Javascript book? I Am Here <iamhereintheworld@gmail.com> - 2012-10-08 06:35 -0700
    Re: What's a good Javascript book? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-08 13:52 +0000
      Re: What's a good Javascript book? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-08 17:03 +0300
        Re: What's a good Javascript book? Tim Streater <timstreater@greenbee.net> - 2012-10-08 15:22 +0100
          Re: What's a good Javascript book? "Mel Smith" <med_cutout_syntel@aol.com> - 2012-10-08 08:56 -0600
    Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-08 16:11 +0200
      Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-09 10:43 +0100
        Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-09 13:12 +0200
          Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-10 15:32 +0100
            Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-10 20:13 +0200
              Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-11 14:28 +0100
        Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-09 17:56 +0100
          Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-10 00:32 +0200
            Re: What's a good Javascript book? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-10-09 16:37 -0700
            Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-10 06:44 +0100
              Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-10 20:09 +0200
              Re: What's a good Javascript book? Dr J R Stockton <reply1241@merlyn.demon.co.uk.invalid> - 2012-10-11 19:43 +0100
    Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-08 16:21 +0200
    Re: What's a good Javascript book? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-10-08 07:56 -0700
    Re: What's a good [JavaScript] book? Matt McDonald <matt@fortybelow.ca> - 2012-10-08 11:38 -0400
      Re: What's a good [JavaScript] book? Matt McDonald <matt@fortybelow.ca> - 2012-10-08 11:42 -0400
        Re: What's a good [JavaScript] book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-10 00:41 +0200
    Re: What's a good Javascript book? Danny <dann90038@gmail.com> - 2012-10-08 11:57 -0700
      Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-08 20:39 +0100
    Re: What's a good Javascript book? I Am Here <iamhereintheworld@gmail.com> - 2012-10-09 06:19 -0700
      Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-09 18:43 +0200
        Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 10:06 -0700
          Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-09 11:43 -0700
            Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-09 20:07 +0100
            Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 13:40 -0700
          Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-09 20:55 +0200
            Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 13:45 -0700
            Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-10 04:31 -0700
        Re: What's a good Javascript book? Stefan Weiss <krewecherl@gmail.com> - 2012-10-09 20:09 +0200
          Re: What's a good Javascript book? Gregor Kofler <usenet@gregorkofler.com> - 2012-10-09 21:01 +0200
            Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-09 13:50 -0700
        Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-10 15:26 +0100
          Re: What's a good Javascript book? Tim Streater <timstreater@greenbee.net> - 2012-10-10 15:58 +0100
            Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-11 14:39 +0100
              Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-11 06:52 -0700
                Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-11 17:13 +0100
                  Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-11 10:39 -0700
                    Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-12 10:37 +0100
                      Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-12 07:11 -0700
                        Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-13 10:53 +0100
                      Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-12 09:49 -0700
                        Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-12 10:22 -0700
                          Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-12 13:17 -0700
                      Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-12 20:32 +0100
                        Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-13 10:50 +0100
                          Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-13 19:45 +0100
                            Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-13 21:55 +0200
                              Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-13 21:52 +0100
                                Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-13 23:49 +0200
                                  Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-13 23:57 +0200
                                  Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-13 23:34 +0100
                                    Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-14 02:09 +0200
                                  Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-14 00:00 +0100
                                    Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-14 01:58 +0200
                                      Re: What's a good Javascript book? Patricia Shanahan <pats@acm.org> - 2012-10-14 07:17 +0100
                                        Re: What's a good Javascript book? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-15 01:17 +0200
                            Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-14 13:40 +0100
                              Re: What's a good Javascript book? Gene Wirchenko <genew@ocis.net> - 2012-10-14 19:03 -0700
                                Re: What's a good Javascript book? John G Harris <john@nospam.demon.co.uk> - 2012-10-15 10:42 +0100
      Re: What's a good Javascript book? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-09 22:49 +0200
    Re: What's a good Javascript book? Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-09 12:00 -0700
    Re: What's a good Javascript book? I Am Here <iamhereintheworld@gmail.com> - 2012-10-16 06:57 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#16560

On Thu, 11 Oct 2012 at 06:52:29, in comp.lang.javascript, Scott Sauyet
wrote:
>John G Harris wrote:
>> Tim Streater wrote:
>>> John G Harris  wrote:
>>>> Gregor Kofler wrote:
>
>>>>> So far Crockford's "JS The Good Parts" has been the only JS book I
>>>>> found worth reading.
>
>>>>  His code for emulating Java-like constructors and inheritance are an
>>>> example of horrible software design, and his reason for doing this is
>>>> remarkably feeble.
>
>>> As are any reasons he might advance for having written the book in the
>>> first place. As has already been said, it's merely one man's opinion
>>> about what constitutes good style.
>
>> It's worse than just his personal style. He tells lies about the
>> language as well.
>
>For example?
>
>I've found many places where I disagree with his opinions, but I
>haven't noticed anything that look like lies to me.  What have you
>seen?

See my book review in this news group dated 11 Jul 2009 with message ID
  8E0bVrInWNWKFw0J@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD

  John
-- 
John Harris

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

#16561

John G Harris wrote:
> Scott Sauyet wrote:
>> John G Harris wrote:

[RE: Crockford's _JavaScript: The Good Parts]

>>> It's worse than just his personal style. He tells lies about the
>>> language as well.
>
>> For example?
>
>> I've found many places where I disagree with his opinions, but I
>> haven't noticed anything that look like lies to me.  What have you
>> seen?
>
> See my book review in this news group dated 11 Jul 2009 with message ID
>   8E0bVrInWNWKFw0J@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD

I did find it archived at

    <https://groups.google.com/group/comp.lang.javascript/msg/
e798d5c2bf041b0b>

I really didn't see anything in your list that seemed likely to be
considered a lie.  The only comment that you made there that might
possibly be construed as a belief that he was lying was this:


| 3  He says that a property's value cannot be 'undefined'. This is
| untrue. (p20)

Even here, I would have taken it to mean that he was mistaken and not
that he was lying.

Odd.

  -- Scott

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

#16575

On Thu, 11 Oct 2012 at 10:39:59, in comp.lang.javascript, Scott Sauyet
wrote:

  <snip>
>I did find it archived at
>
>    <https://groups.google.com/group/comp.lang.javascript/msg/
>e798d5c2bf041b0b>
>
>I really didn't see anything in your list that seemed likely to be
>considered a lie.  The only comment that you made there that might
>possibly be construed as a belief that he was lying was this:
>
>
>| 3  He says that a property's value cannot be 'undefined'. This is
>| untrue. (p20)
>
>Even here, I would have taken it to mean that he was mistaken and not
>that he was lying.
>
>Odd.

1) His is the *only* good coding style.
2) else is *always* followed by { ... } .
3) He says that { ... } is not a statement.
4) He says, or implies by banning it, that there is never a good reason
   to call a constructor as an ordinary function.

The first is arrogance. The second contradicts what he puts in the
syntax diagrams.

Teaching the third and fourth to beginners should be made a criminal
offence. To be fair to him (why? -ed) the book does start by saying it's
not for beginners. On the other hand he says the book is for programmers
new to the language, so I'm being too fair.

  John
-- 
John Harris

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

#16577

John G Harris  wrote:
> Scott Sauyet wrote:

[RE: Crockford's _JavaScript: The Good Parts]
>     <https://groups.google.com/group/comp.lang.javascript/msg/e798d5c2bf041b0b>
>
>> I really didn't see anything in your list that seemed likely to be
>> considered a lie.  [ ... ]
>
> 1) His is the *only* good coding style.
> 2) else is *always* followed by { ... } .
> 3) He says that { ... } is not a statement.
> 4) He says, or implies by banning it, that there is never a good reason
>    to call a constructor as an ordinary function.
>
> The first is arrogance. The second contradicts what he puts in the
> syntax diagrams.
>
> Teaching the third and fourth to beginners should be made a criminal
> offence. To be fair to him (why? -ed) the book does start by saying it's
> not for beginners. On the other hand he says the book is for programmers
> new to the language, so I'm being too fair.

Obviously we have very different notions of what it means to lie.

I disagree with Crockford, but I probably also disagree with you on
some of these points.  I don't think you're lying about them.

  -- Scott

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

#16599

On Fri, 12 Oct 2012 at 07:11:56, in comp.lang.javascript, Scott Sauyet
wrote:

  <snip>
>Obviously we have very different notions of what it means to lie.
  <snip>

I mean telling an untruth that misleads the innocent to their detriment,
and not through the author's carelessness or ignorance.

  John
-- 
John Harris

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

#16579

On Fri, 12 Oct 2012 10:37:06 +0100, John G Harris
<john@nospam.demon.co.uk> wrote:

[snip]

>1) His is the *only* good coding style.

     This is enough to say no.  I have a coding style I prefer.  It
may be better than yours, but how would I know unless I know what you
work with/in/on?

     Even if it is better, it might only be better in the areas that I
work in.  Or either of our styles might work fine.

     It is like "best practices".  You are not against best practices,
are you?  How could you be against best practices?  The label is not
the thing.

[snip]

Sincerely,

Gene Wirchenko

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

#16581

Gene Wirchenko wrote:
>  John G Harris wrote:
 [RE: Crockford's _JavaScript: The Good Parts]

>> 1) His is the *only* good coding style.
>
> This is enough to say no.  I have a coding style I prefer.  It
> may be better than yours, but how would I know unless I know what you
> work with/in/on?

Just remember that the above is not a quote, only John's
interpretation of Crockford's book.

Crockford absolutely is opinionated about style, and JSLint captures
his opinions in a very detailed manner.  This book is very opinionated
as well, but probably less so about style than about more fundamental
issues.

  -- Scott

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

#16591

On Fri, 12 Oct 2012 10:22:15 -0700 (PDT), Scott Sauyet
<scott.sauyet@gmail.com> wrote:

>Gene Wirchenko wrote:
>>  John G Harris wrote:
> [RE: Crockford's _JavaScript: The Good Parts]
>
>>> 1) His is the *only* good coding style.
>>
>> This is enough to say no.  I have a coding style I prefer.  It
>> may be better than yours, but how would I know unless I know what you
>> work with/in/on?
>
>Just remember that the above is not a quote, only John's
>interpretation of Crockford's book.
>
>Crockford absolutely is opinionated about style, and JSLint captures
>his opinions in a very detailed manner.  This book is very opinionated
>as well, but probably less so about style than about more fundamental
>issues.

     I am opinionated, too, but I do not cram it down people's
throats.  I tried JSLint, saw that it was catering to prejudices
rather than actual language requirements, and dropped it.

Sincerely,

Gene Wirchenko

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

#16589

John G Harris wrote:
> On Thu, 11 Oct 2012 at 10:39:59, in comp.lang.javascript, Scott Sauyet
> wrote:
> 
>   <snip>
>> I did find it archived at
>>
>>    <https://groups.google.com/group/comp.lang.javascript/msg/
>> e798d5c2bf041b0b>
>>
>> I really didn't see anything in your list that seemed likely to be
>> considered a lie.  The only comment that you made there that might
>> possibly be construed as a belief that he was lying was this:
>>
>>
>> | 3  He says that a property's value cannot be 'undefined'. This is
>> | untrue. (p20)
>>
>> Even here, I would have taken it to mean that he was mistaken and not
>> that he was lying.
>>
>> Odd.
> 
> 1) His is the *only* good coding style.

I've met a lot of people who, completely honestly and sincerely, believe
their preferred style is the only good coding style in some language.
Perhaps he is one of those people, and is expressing what he believes.

> 2) else is *always* followed by { ... } .
> 3) He says that { ... } is not a statement.
> 4) He says, or implies by banning it, that there is never a good reason
>    to call a constructor as an ordinary function.
> 

Depending on the context and exactly what he wrote, he may be at least
half right about #3.

According to the grammar in
http://www.ecma-international.org/ecma-262/5.1/, Statement can be
expanded to Block, so some blocks are statements. On the other hand,
there are contexts which require Block rather than Statement, for
example in a TryStatement. A block that appears where a statement is not
permitted cannot be a statement.

Following an else is not one of those contexts, so #2 is wrong.

Patricia

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

#16598

On Fri, 12 Oct 2012 at 20:32:57, in comp.lang.javascript, Patricia
Shanahan wrote:

  <snip>
>According to the grammar in
>http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>expanded to Block, so some blocks are statements. On the other hand,
>there are contexts which require Block rather than Statement, for
>example in a TryStatement. A block that appears where a statement is not
>permitted cannot be a statement.
  <snip>

I don't agree with your reasoning there. The standard says 'try' must be
followed by a block statement. If it said that 'try' must be followed by
an if statement that wouldn't stop the if production being a particular
kind of statement. It's merely unusual for there to be any kind of
restriction on what kind of statement can be used in a particular
context.

Also, where you say "so some blocks are statements" you've got it the
wrong way round : so some statements are blocks.

  John
-- 
John Harris

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

#16604

John G Harris wrote:
> On Fri, 12 Oct 2012 at 20:32:57, in comp.lang.javascript, Patricia
> Shanahan wrote:
> 
>   <snip>
>> According to the grammar in
>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>> expanded to Block, so some blocks are statements. On the other hand,
>> there are contexts which require Block rather than Statement, for
>> example in a TryStatement. A block that appears where a statement is not
>> permitted cannot be a statement.
>   <snip>
> 
> I don't agree with your reasoning there. The standard says 'try' must be
> followed by a block statement. If it said that 'try' must be followed by

Could you give me a reference for where you are getting the phrase
"block statement"?

I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
recently downloaded copy of
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
and without finding the phrase. Maybe there is some other document I
should be consulting. If so, please give me a pointer.

> an if statement that wouldn't stop the if production being a particular
> kind of statement. It's merely unusual for there to be any kind of
> restriction on what kind of statement can be used in a particular
> context.
> 
> Also, where you say "so some blocks are statements" you've got it the
> wrong way round : so some statements are blocks.

"some statements are blocks" is true, but I did not think it was in any
way in dispute. It contradicts neither "some blocks are statements" nor
"some blocks are not statements".

Patricia

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

#16606

Patricia Shanahan wrote:

> John G Harris wrote:
>> Patricia Shanahan wrote:
>>   <snip>
>>> According to the grammar in
>>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>>> expanded to Block, so some blocks are statements. On the other hand,
>>> there are contexts which require Block rather than Statement, for
>>> example in a TryStatement. A block that appears where a statement is not
>>> permitted cannot be a statement.
>>   <snip>
>> 
>> I don't agree with your reasoning there. The standard says 'try' must be
>> followed by a block statement. If it said that 'try' must be followed by
> 
> Could you give me a reference for where you are getting the phrase
> "block statement"?
> 
> I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
> recently downloaded copy of
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
> and without finding the phrase. Maybe there is some other document I
> should be consulting. If so, please give me a pointer.

Section "12.1 Block" of the ECMAScript Language Specification, 5.1 Edition 
(and all previous Editions; section numbering may differ) is a subsection of 
section "12 Statements".  That, the productions for the /Statement/ goal 
symbol defined in the latter section –

| Statement :
|   Block
|   VariableStatement
|   EmptyStatement
|   ExpressionStatement
|   IfStatement
|   IterationStatement
|   ContinueStatement
|   BreakStatement
|   ReturnStatement
|   WithStatement
|   LabelledStatement
|   SwitchStatement
|   ThrowStatement
|   TryStatement
|   DebuggerStatement

(previous Editions contain the productions starting from LabelledStatement 
to a varying degree) –, and that an ECMAScript program is produced from

| 14 Program
| 
| Syntax
| 
| Program :
|   SourceElements_opt
| 
| SourceElements :
|   SourceElement
|   SourceElements SourceElement
| 
| SourceElement :
|   Statement
|   FunctionDeclaration

specify that what can be produced from the Block goal symbol is considered a 
statement, or, IOW, that there is a Block statement.  This may be 
colloquially written "block statement".

The syntax for "12.14 The try Statement" (which *also* is a subsection of 
section 12) is:

| TryStatement :
|   try Block Catch
|   try Block Finally
|   try Block Catch Finally
| 
| Catch :
|   catch ( Identifier ) Block
| 
| Finally :
|   finally Block

This means that the `try' keyword must be followed by a statement, 
specifically a Block statement.

That there is a Block statement and a LabelledStatement in ECMAScript is one 
reason why

  return
  {
    foo: "bar"
  };

produces unexpected results as it is equivalent to

  return;

  {
    foo: "bar";
  };

where the `undefined' value is returned and `foo' is considered a label for 
the "bar" ExpressionStatement.  Which has been correctly observed by 
Crockford, among others.

[His conclusion from that, that Allman style is inappropriate on the whole 
in ECMAScript implementations is premature and fallacious, though.  For it 
is exactly the ambiguity between Block statements and Object initializers, 
and Function declarations and Function expressions that makes it a good idea 
to format them differently:

  if (foo)
  {
    bar();
  }

but

  return {
    foo: "bar"
  };

and

  function foo (bar)
  { 
    baz();
  }

but

  var foo = function (bar) {
    baz();
  };

and, by extension, 

  var foo = (function (baz) {
    return function bar (foobar) {
      return foobar(bar, baz);
    };
  }(42));

]


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

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

#16609

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
> 
>> John G Harris wrote:
>>> Patricia Shanahan wrote:
>>>   <snip>
>>>> According to the grammar in
>>>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>>>> expanded to Block, so some blocks are statements. On the other hand,
>>>> there are contexts which require Block rather than Statement, for
>>>> example in a TryStatement. A block that appears where a statement is not
>>>> permitted cannot be a statement.
>>>   <snip>
>>>
>>> I don't agree with your reasoning there. The standard says 'try' must be
>>> followed by a block statement. If it said that 'try' must be followed by
>> Could you give me a reference for where you are getting the phrase
>> "block statement"?
>>
>> I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
>> recently downloaded copy of
>> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf,
>> and without finding the phrase. Maybe there is some other document I
>> should be consulting. If so, please give me a pointer.
> 
> Section "12.1 Block" of the ECMAScript Language Specification, 5.1 Edition 
> (and all previous Editions; section numbering may differ) is a subsection of 
> section "12 Statements".  That, the productions for the /Statement/ goal 
> symbol defined in the latter section –
> 
> | Statement :
> |   Block
> |   VariableStatement
> |   EmptyStatement
> |   ExpressionStatement
> |   IfStatement
> |   IterationStatement
> |   ContinueStatement
> |   BreakStatement
> |   ReturnStatement
> |   WithStatement
> |   LabelledStatement
> |   SwitchStatement
> |   ThrowStatement
> |   TryStatement
> |   DebuggerStatement

I find it interesting that the symbol is "Block", not "BlockStatement".
Things that can only be used as a Statement, such as IfStatement, get
the word "Statement" in their symbols.

> specify that what can be produced from the Block goal symbol is considered a 
> statement, or, IOW, that there is a Block statement.  This may be 
> colloquially written "block statement".

You seem to be confused about my position. I am not saying that no Block
can be a Statement, just that a Block can be used in situations in which
a Statement would not be accepted, and so is not always a Statement.

I have no trouble with colloquially calling those blocks that are
statements "block statements", but do not think colloquial usage is a
good way of analyzing language specifications.

Patricia

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

#16613

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> John G Harris wrote:
>>>> Patricia Shanahan wrote:
>>>>   <snip>
>>>>> According to the grammar in
>>>>> http://www.ecma-international.org/ecma-262/5.1/, Statement can be
>>>>> expanded to Block, so some blocks are statements. On the other hand,
>>>>> there are contexts which require Block rather than Statement, for
>>>>> example in a TryStatement. A block that appears where a statement is
>>>>> not permitted cannot be a statement.
>>>>   <snip>
>>>>
>>>> I don't agree with your reasoning there. The standard says 'try' must
>>>> be followed by a block statement. If it said that 'try' must be
>>>> followed by

(sic!)

BTW, interrupting others in the midst of a sentence is not good quoting 
style either.

>>> Could you give me a reference for where you are getting the phrase
>>> "block statement"?
>>>
>>> I've searched both http://www.ecma-international.org/ecma-262/5.1/ and a
>>> recently downloaded copy of
>>> http://www.ecma-international.org/publications/files/ECMA
>>> ST/Ecma-262.pdf, and without finding the phrase. Maybe there is some
>>> other document I should be consulting. If so, please give me a pointer.
>> 
>> Section "12.1 Block" of the ECMAScript Language Specification, 5.1
>> Edition (and all previous Editions; section numbering may differ) is a
>> subsection of section "12 Statements".  That, the productions for the
>> /Statement/ goal symbol defined in the latter section –
>> 
>> | Statement :
>> |   Block
>> |   VariableStatement
>> |   EmptyStatement
>> |   ExpressionStatement
>> |   IfStatement
>> |   IterationStatement
>> |   ContinueStatement
>> |   BreakStatement
>> |   ReturnStatement
>> |   WithStatement
>> |   LabelledStatement
>> |   SwitchStatement
>> |   ThrowStatement
>> |   TryStatement
>> |   DebuggerStatement
> 
> I find it interesting that the symbol is "Block", not "BlockStatement".

The goal symbol right-hand side is irrelevant, as the Specification is 
structured in sections so that it is clear what is a statement and what is 
not.  And the goal symbol left-hand side emphasizes that.

> Things that can only be used as a Statement, such as IfStatement, get
> the word "Statement" in their symbols.

Nonsense.
 
>> specify that what can be produced from the Block goal symbol is
>> considered a
>> statement, or, IOW, that there is a Block statement.  This may be
>> colloquially written "block statement".
> 
> You seem to be confused about my position. I am not saying that no Block
> can be a Statement, just that a Block can be used in situations in which
> a Statement would not be accepted, and so is not always a Statement.

Ex falso quodlibet.  A Block (statement) *cannot* be used in situations in 
which a Statement would not be accepted.  For example, the braces in

  function x (y)
  {
    
  }
 
are _not_ produced by /Block/, they are produced as part of

| FunctionDeclaration :
|   function Identifier ( FormalParameterListopt ) { FunctionBody }

The braces in

  var foo = {
    bar: 42
  };

are _not_ produced by /Block/ either, they are produced as part of

| ObjectLiteral :
|   { }
|   { PropertyNameAndValueList }
|   { PropertyNameAndValueList , }

(formerly, /ObjectInitialiser/, and a trailing comma was a syntax error).


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#16615

Thomas 'PointedEars' Lahn wrote:

> | ObjectLiteral :
> |   { }
> |   { PropertyNameAndValueList }
> |   { PropertyNameAndValueList , }
> 
> (formerly, /ObjectInitialiser/, […]).

I have confused that.  It was /ObjectLiteral/ in Edition 3 already, and the 
prose always used "Object Initialiser" for the section name regardless.


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#16618

Thomas 'PointedEars' Lahn wrote:
...
> The goal symbol right-hand side is irrelevant, as the Specification is 
> structured in sections so that it is clear what is a statement and what is 
> not.  And the goal symbol left-hand side emphasizes that.
...

I don't think you really mean to argue that being defined in Section 12
makes it clear that a symbol is a Statement, rather than just something
so closely related to statements that it makes sense to put it in the
same section.

See, for example, the Section 12 production

Initialiser :
   = AssignmentExpression

Patricia

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

#16626

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> The goal symbol right-hand side is irrelevant, as the Specification is
>> structured in sections so that it is clear what is a statement and what
>> is not.  And the goal symbol left-hand side emphasizes that.
> 
> I don't think you really mean to argue that being defined in Section 12
> makes it clear that a symbol is a Statement, rather than just something
> so closely related to statements that it makes sense to put it in the
> same section.

Of course I do mean that.  It is not logical to think otherwise.
 
> See, for example, the Section 12 production
> 
> Initialiser :
>    = AssignmentExpression

Quoting the Specification out of context does not help your case.  The 
Initialiser goal symbol is on the right-hand side of the 
/VariableDeclaration/ production in section "12.2 Variable Statement".  A 
/VariableDeclaration/ can only be produced as part of a /VariableStatement/, 
through /VariableDeclarationList/, which can only be produced by 
/Statement/.

Very obviously all possible outcomes of the /Statement/ production produce a 
statement each in these programming languages.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

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

#16623

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
...
>> You seem to be confused about my position. I am not saying that no Block
>> can be a Statement, just that a Block can be used in situations in which
>> a Statement would not be accepted, and so is not always a Statement.
> 
> Ex falso quodlibet.  A Block (statement) *cannot* be used in situations in 
> which a Statement would not be accepted.  For example, the braces in
> 
>   function x (y)
>   {
>     
>   }
>  
> are _not_ produced by /Block/, they are produced as part of
> 
> | FunctionDeclaration :
> |   function Identifier ( FormalParameterListopt ) { FunctionBody }
> 
> The braces in
> 
>   var foo = {
>     bar: 42
>   };
> 
> are _not_ produced by /Block/ either, they are produced as part of
> 
> | ObjectLiteral :
> |   { }
> |   { PropertyNameAndValueList }
> |   { PropertyNameAndValueList , }
> 
> (formerly, /ObjectInitialiser/, and a trailing comma was a syntax error).

Have you considered the TryStatement productions?

Patricia

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

#16625

Patricia Shanahan wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Patricia Shanahan wrote:
>>> You seem to be confused about my position. I am not saying that no Block
>>> can be a Statement, just that a Block can be used in situations in which
>>> a Statement would not be accepted, and so is not always a Statement.
>> 
>> Ex falso quodlibet.  A Block (statement) *cannot* be used in situations
>> in which a Statement would not be accepted.  For example, the braces in
>> 
>>   function x (y)
>>   {
>>     
>>   }
>>  
>> are _not_ produced by /Block/, they are produced as part of
>> 
>> | FunctionDeclaration :
>> |   function Identifier ( FormalParameterListopt ) { FunctionBody }
>> 
>> The braces in
>> 
>>   var foo = {
>>     bar: 42
>>   };
>> 
>> are _not_ produced by /Block/ either, they are produced as part of
>> 
>> | ObjectLiteral :
>> |   { }
>> |   { PropertyNameAndValueList }
>> |   { PropertyNameAndValueList , }
>> 
>> (formerly, /ObjectInitialiser/, and a trailing comma was a syntax error).
> 
> Have you considered the TryStatement productions?

I have, and that is indeed a case where any other statement but a Block 
statement is not allowed.  However, that does not prove your argument,
only its premise.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

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

#16628

Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
...
>> Have you considered the TryStatement productions?
> 
> I have, and that is indeed a case where any other statement but a Block 
> statement is not allowed.  However, that does not prove your argument,
> only its premise.

In that case, we may have to just agree to differ. You seem to have a
very deeply built-in assumption that a Block must be a Statement, to the
extent that even when discussing the standard you talk about "a Block
statement", a phrase that does not appear in it, rather than terms such
as "a Block" or "a Block of code", that do appear in the standard.

However, I am very curious about why you wrote so much that seemed to be
refuting the idea that any sequence of statements enclosed in braces
must be a Block. I never claimed that, and it has nothing to do with my
actual claim, which was about Block, not about all brace-enclosed
statement sequences.

Patricia

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web