statement values

[Thomas 'PointedEars' Lahn]

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

 

[VK]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[VK]

The `type' attribute is missing.


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.

 

[Thomas 'PointedEars' Lahn]

You snipped, probably intentionally:

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

 

[John G Harris]

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.

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 G Harris]

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

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Mon, 7 Jan 2008 19:58:43, John G Harris

Pascal has the Empty Statement, back in 1970.

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

 

[VK]

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

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?

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.


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


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

 

[Thomas 'PointedEars' Lahn]

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

 

[Anthony Levensalor]

Thomas 'PointedEars' Lahn said:

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've always thought of code more as poetry than anything mystical,
magical, or quasi-religious. I let the end users think it's magic, I
enjoy the structure, the rhythm, the flippy funny doohickey of it all, I
suppose.

Another unnecessary post from:

~A!