statement values

You have yet to understand what it means when something is called an
ECMAScript implementation. *But as you insist, I am not going to prevent
you making a fool out of yourself.

Score adjusted

I understand exactly what it means Thomas. Do you spend your whole day
being a presumptuous ass, are do you have other tricks?

but they do not go into resulting execution code

Which would explain the behavior of the eval function in this case.
Thanks VK for your insightful and knowledgeable post and for actually
addressing the OP's question.

You have yet to understand what it means when something is called an
ECMAScript implementation. But as you insist, I am not going to prevent
you making a fool out of yourself.

Score adjusted

I understand exactly what it means Thomas. Do you spend your whole
day
being a presumptuous ass, or do you have other tricks?

Doug Gunnoe wrote:

You have yet to understand what it means when something is called an
ECMAScript implementation. But as you insist, I am not going to prevent
you making a fool out of yourself.

Score adjusted

I understand exactly what it means Thomas.

No, you don't. If you did, you would not only have recognized section 2 of
the ECMAScript Specification but also the number of differences between the
implementations that result from that, which we have discussed here ad
nauseam before.

http://PointedEars.de/scripts/es-matrix

Do you spend your whole day being a presumptuous ass, [...]

I leave that to people who are more skilled in it.


Please provide an attribution line as also recommended in the FAQ.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Doug Gunnoe wrote:

but they do not go into resulting execution code

Which would explain the behavior of the eval function in this case.
Thanks VK for your insightful and knowledgeable post and for actually
addressing the OP's question.

ROTFL. YMMD.


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

No, you don't.

Sure I do.

If you did, you would not only have recognized section 2 of
the ECMAScript Specification

Why is that? Your statement was

You have yet to understand what it means when something is called an
ECMAScript implementation.

Yeah, a 'specification' is such a very difficult concept to grasp.
Congratulations on being smart.

but also the number of differences between the
implementations that result from that,

In the context of the question from the OP, there was no difference in
the results he was getting from the implementations he tested. From
the OP:

All engines I tried (Rhino, FF and Konqueror) however return '3', as
if the the evaled body was in a block. (According to 12.1 inside a
block the last statement not returning 'empty' is used as return
value).

Thomas
I leave that to people who are more skilled in it.

Oh, you are skilled at it.

And thanks for contributing nothing to the discussion.

On Thu, 3 Jan 2008 at 14:01:20, in comp.lang.javascript, wrote:

According to the spec Section 14 the production
SourceElements:SourceElements SourceElement is evaluated as follows:
1. Evaluate SourceElements.
2. If Result(1) is an abrupt completion, return Result(1)
3. Evaluate SourceElement.
4. Return Result(3).

If I understood correctly the following program should alert
'undefined':
alert(eval('3;;'));
The last source-element would be ";" (the empty statement), and this
statement returns 'empty' as value (12.3) which is then transformed to
'undefined' by the eval (15.1.2.1).
All engines I tried (Rhino, FF and Konqueror) however return '3', as
if the the evaled body was in a block. (According to 12.1 inside a
block the last statement not returning 'empty' is used as return
value).
Is this a bug in these engines, or did I misinterpret the spec?
snip

It looks like a bug, somewhere.

You're using statements indirectly as arguments in a function call. This
is sufficiently peculiar that you should expect either an unexpected
result, or a bug in the engine, or a bug in the specification. I think
it best to suspect the last of these. It's another example of eval being
evil.

John
--
John Harris

On Thu, 3 Jan 2008 at 14:01:20, in comp.lang.javascript, wrote:

<snip>

Another question for VariableDeclarations:
Why does the production 'VariableDeclaration: Identifier' and the
production
'VariableDeclaration: Identifier Initialiser' return a sequence of
characters? I can't find how these strings could be used.

I suspect the answer is that well known reason "It seemed a good idea at
the time".

There is some slight excuse. The code that sets up an execution scope
needs to know the names of the variables it must create. The rule for
executing a VariableDeclaration : Identifier statement during
execution gives the name that was needed. It's a pretty feeble excuse.

John
--
John Harris

On Sat, 5 Jan 2008 at 10:52:40, in comp.lang.javascript, VK wrote:

<snip>

If you are referring to "12.3 Empty Statement" then this is plain bs
to disregard: it shows nothing but poor understanding by authors the
subject they had to write on. Obviously they considered the semicolon
as some kind of "statement" or "statement formant", other words
something that exists or leaves some signs *at runtime* so to be
"evaluated".

Again: the JavaScript production is semi-similar - in the most generic
sense of course - to Java. In Java we have raw source as .java file
and .class bytecode parsed out of the raw source to be served to the
client. Client-side this intermediary bytecode finally gets converted
to the machine execution code.
JavaScript is served as raw source right away to client and
"bytecode" (sequence of tokens) is being made client-side right on
arrival. No attempt to execute this code is made on this stage, the
parser is only cares if a valid sequence of valid tokens can be made
from the received source. If any error on this stage then one gets one
of syntax errors. Semicolons do participate in this stage by helping
to extract tokens from the source but they do not go into resulting
execution code - lets keep calling it "bytecode" though formally it is
not a correct term. This way there is not any EmptyExpression to be
"evaluated".
snip

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.

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.

John
--
John Harris

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

First of all you are getting _syntax_ error. If you are getting
_syntax_ error we are by definition not dealing with the _execution_
problems.

Secondly try this code instead:

<script>
if (false) \u000A else true
alert('Parser is happy');
</script>

Thirdly make yourself a memory dump at runtime (or ask someone to
prepare it for you) to make sure that:

1) if (false) \u000A else true

2) if (false)
;
else
true

3) if (false) {} else {true}

on the execution stage are being resulted into byte-to-byte exactly
the same scavengers.

The major problem of ECMAScript specs is that starting from the first
page and till the last line they couldn't take a decision what are
they writing: a description of a standard-compliant engine, language
syntax description or a programmer's guide. As the result we are
having now a very esoteric book there the narration goes from internal
parsing to if-else usage, then to suggested var naming, then back to
the internal engine mechanics and so on. It doesn't make it wrong: it
just make it a very confusing source to learn the language itself. My
suggestion would be for anyone studying the language to pretend for
the first year at least that there is not ECMA specs at all.

P.S.

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();}

or better yet use assembly style, that makes your code more readable
and easier to alter in the future:

if (something) {
/* NOP */
}
else {
do_this();
}