statement values

VK wrote:

On Jan 6, 3:40 pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:
Here's an example that destroys VK's argument :

if (x)
;
else
x = 3;

The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten.

Right the opposite, it makes my case even stronger (about some free-
lancers filling some - but not all - specs templates back in 90's).

It doesn't.

First of all you are getting _syntax_ error. [...]

No, anyone outside of your parallel universe does not get a syntax error.

This group would benefit most from your dreaming your fantasies elsewhere.


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

On Jan 7, 12:47 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

VK wrote:
On Jan 6, 3:40 pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:
Here's an example that destroys VK's argument :

if (x)
;
else
x = 3;

The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten.

Right the opposite, it makes my case even stronger (about some free-
lancers filling some - but not all - specs templates back in 90's).

It doesn't.

First of all you are getting _syntax_ error. [...]

No, anyone outside of your parallel universe does not get a syntax error.

Use some descent (more-or-less standard compliant) browser then:

<script>
if (x)
else
x = 3;
</script>

gives:

Fx: Tools > Error Console
"Error: syntax error"

IE (error message allowed):
"Syntax Error"

feel free to try on Opera, Safari or any other off your fantasy. I'm
paying $$ for each _runtime_ error

VK wrote:

On Jan 7, 12:47 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
wrote:
VK wrote:
On Jan 6, 3:40 pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:
Here's an example that destroys VK's argument :
if (x)
;
else
x = 3;
The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten.
Right the opposite, it makes my case even stronger (about some free-
lancers filling some - but not all - specs templates back in 90's).
It doesn't.

First of all you are getting _syntax_ error. [...]
No, anyone outside of your parallel universe does not get a syntax error.

Use some descent (more-or-less standard compliant) browser then:

script

The `type' attribute is missing.

if (x)
else
x = 3;

That is _not_ the example John gave above. You will get a syntax error with
*yours*, because your assumption that `;' is not a(n empty) statement and is
only important as a "parser helper" and all the conclusions you have
subsequently jumped to are complete utter nonsense.


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

On Jan 7, 1:29 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

The `type' attribute is missing.

if (x)
else
x = 3;

That is _not_ the example John gave above. You will get a syntax error with
*yours*, because your assumption that `;' is not a(n empty) statement and is
only important as a "parser helper"

Very true: it just not an assumption but exactly how any compliant
engine mechanics work.

if (x)
;
else
x = 3;

and

if (x)
else
x = 3;

are only different that the firs one gives enough info to parser to
build a valid token chain and the second does not so leads to a syntax
error. There is not any mythical EmptyExpression involved in neither
case because it has no relation to the runtime (actual code
execution). From John's comments to his sample:
"The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten."
- one could wrongly conclude that if-else statement requires at least
one expression in the if-branch or it will error out at runtime. There
is not such requirement for if-else and
if (x) {} else {}
is a perfectly valid - though rather useless - construct.

There is i) the parsing stage when parser tries to build a valid
sequence of valid tokens and gives syntax errors if no way, and ii)
execution stage when the engine is actually trying to execute
requested part of resulted tokens and gives runtime errors if no way.
These are two absolutely different unrelated stages. Semicolons are
used on the first (parsing) stage; there is not any smell of them on
the second (execution) stage.

For further fun of it:

<script>
var code = 'if (true) {3;;}';
alert(eval(code)); // 3
</script>

but the main proof is the memory state of course - if anyone still
feel to be needed a proof of something.

VK wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:
The `type' attribute is missing.

if (x)
else
x = 3;
That is _not_ the example John gave above. You will get a syntax error with
*yours*, because your assumption that `;' is not a(n empty) statement and is
only important as a "parser helper"

You snipped, probably intentionally:

and all the conclusions you have subsequently jumped to are complete
utter nonsense.

Very true: it just not an assumption but exactly how any compliant
engine mechanics work.

No, it isn't. You have already been proven wrong.


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

On Sun, 6 Jan 2008 at 13:27:40, in comp.lang.javascript, VK wrote:

On Jan 6, 3:40 pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:
Here's an example that destroys VK's argument :

if (x)
;
else
x = 3;

The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten.

Right the opposite, it makes my case even stronger (about some free-
lancers filling some - but not all - specs templates back in 90's).

Pascal has the Empty Statement, back in 1970.


<snip>

Incidentally, that semicolon can't be left out. If you want to do
nothing you have to write the semicolon to show you really mean it.

I don't really like to torture the syntax like that :-) To do nothing
simply use brackets:

if (something) {} else {do_this();}
snip

Now you're talking about coding styles : empty statement versus empty
block statement.

Also, if ; is syntax torture then so is {}.

John
--
John Harris

On Mon, 7 Jan 2008 at 07:46:32, in comp.lang.javascript, VK wrote:

On Jan 7, 1:29 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
wrote:
The `type' attribute is missing.

if (x)
else
x = 3;

That is _not_ the example John gave above. You will get a syntax error with
*yours*, because your assumption that `;' is not a(n empty) statement and is
only important as a "parser helper"

Very true: it just not an assumption but exactly how any compliant
engine mechanics work.

if (x)
;
else
x = 3;

and

if (x)
else
x = 3;

are only different that the firs one gives enough info to parser to
build a valid token chain and the second does not so leads to a syntax
error. There is not any mythical EmptyExpression

If you don't know the difference between an expression and a statement
then you shouldn't be talking about syntax.

involved in neither
case because it has no relation to the runtime (actual code
execution). From John's comments to his sample:
"The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten."
- one could wrongly conclude that if-else statement requires at least
one expression

Again, if you don't know the difference between an expression and a
statement then you shouldn't be talking about syntax.

in the if-branch or it will error out at runtime. There
is not such requirement for if-else

The code generator needs to produce code that jumps over the else part.
It's not the job of the code generator to understand the syntax, and
therefore notice that there is (ok) or isn't (error) a statement token
between the if condition and the else part.

and
if (x) {} else {}
is a perfectly valid - though rather useless - construct.

Now explain why an empty block is less 'mythical' than a no-op.

There is i) the parsing stage when parser tries to build a valid
sequence of valid tokens and gives syntax errors if no way, and ii)
execution stage when the engine is actually trying to execute
requested part of resulted tokens and gives runtime errors if no way.
These are two absolutely different unrelated stages. Semicolons are
used on the first (parsing) stage; there is not any smell of them on
the second (execution) stage.
snip

There is no smell because the lonely semicolon has been translated into
an internal token that the code generator/executor understands.

John
--
John Harris

In comp.lang.javascript message <QnKHhvGzRogHFwG9@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Mon, 7 Jan 2008 19:58:43, John G Harris
<john (AT) nospam (DOT) demon.co.uk> posted:

On Sun, 6 Jan 2008 at 13:27:40, in comp.lang.javascript, VK wrote:

Right the opposite, it makes my case even stronger (about some free-
lancers filling some - but not all - specs templates back in 90's).

Pascal has the Empty Statement, back in 1970.

Algol 60 Report :-
4.4.1 Syntax
<dummy statement> ::= <empty>

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.

On Jan 7, 11:45 pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:

On Mon, 7 Jan 2008 at 07:46:32, in comp.lang.javascript, VK wrote:
On Jan 7, 1:29 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de
wrote:
The `type' attribute is missing.

if (x)
else
x = 3;

That is _not_ the example John gave above. You will get a syntax error with
*yours*, because your assumption that `;' is not a(n empty) statement and is
only important as a "parser helper"

Very true: it just not an assumption but exactly how any compliant
engine mechanics work.

if (x)
;
else
x = 3;

and

if (x)
else
x = 3;

are only different that the firs one gives enough info to parser to
build a valid token chain and the second does not so leads to a syntax
error. There is not any mythical EmptyExpression

If you don't know the difference between an expression and a statement
then you shouldn't be talking about syntax.
involved in neither
case because it has no relation to the runtime (actual code
execution). From John's comments to his sample:
"The lonely semicolon must be translated into code that jumps over the
'else' part. It can't be thrown away by the parser and forgotten."
- one could wrongly conclude that if-else statement requires at least
one expression

Again, if you don't know the difference between an expression and a
statement then you shouldn't be talking about syntax.

OK, that's getting boring. Are you gonna talk on the subject or on the
posting style?

in the if-branch or it will error out at runtime. There
is not such requirement for if-else

The code generator needs to produce code that jumps over the else part.
It's not the job of the code generator to understand the syntax, and
therefore notice that there is (ok) or isn't (error) a statement token
between the if condition and the else part.

and
if (x) {} else {}
is a perfectly valid - though rather useless - construct.

Now explain why an empty block is less 'mythical' than a no-op.

There is i) the parsing stage when parser tries to build a valid
sequence of valid tokens and gives syntax errors if no way, and ii)
execution stage when the engine is actually trying to execute
requested part of resulted tokens and gives runtime errors if no way.
These are two absolutely different unrelated stages. Semicolons are
used on the first (parsing) stage; there is not any smell of them on
the second (execution) stage.

snip

There is no smell because the lonely semicolon has been translated into
an internal token that the code generator/executor understands.

Guys (both of you): I am not in disposition to attack anyone's
personal believes. Anyone is entitled to believe or do not believe in
God, paradise, hell, bigfoot, alien conspiracy, EmptyExpressions,
EmptyStatements and anything one would wish.
I'm out of this thread.

VK wrote:

Guys (both of you): I am not in disposition to attack anyone's
personal believes. Anyone is entitled to believe or do not believe in
God, paradise, hell, bigfoot, alien conspiracy, EmptyExpressions,
EmptyStatements and anything one would wish.

It would appear that your problem is *exactly* your thinking that
programming can be understood in religious terms and mystical
incantations. Once you hopefully abandon that notion eventually, it
will become much easier for you to really *understand* how things
work.

I'm out of this thread.

Thanks.


PointedEars