statement values

[florian.loitsch@gmail.com]

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?

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

mfg,
// florian loitsch

[Doug Gunnoe]

Re: statement values

On Jan 3, 4:01 pm, florian.loit... @gmail.com wrote:

According to the spec Section 14 the production
SourceElements: SourceElements SourceElement is evaluated as follows:

Could you elaborate a little more on what you are talking about? What
'spec' do you mean? JavaScript specification?

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

So you are talking about how various JavaScript implementations parse
the script in an instances such as this? And I suppose in particular
how it deals with ';'?

[Doug Gunnoe]

Re: statement values

On Jan 3, 4:01 pm, florian.loit... @gmail.com 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?
>
Another question for VariableDeclara tions:
Why does the production 'VariableDeclar ation: Identifier' and the
production
'VariableDeclar ation: Identifier Initialiser' return a sequence of
characters? I can't find how these strings could be used.
>
mfg,
// florian loitsch

alert(eval('')) ; returns undefined as does alert(eval(';') );

I suppose all of this may have something to do with the fact that ';'
are not needed in javascript.

But alert(eval('3\n \n')) returns three also.

Humm.

[Thomas 'PointedEars' Lahn]

Re: statement values

Doug Gunnoe wrote:

On Jan 3, 4:01 pm, florian.loit... @gmail.com wrote:

>According to the spec Section 14 the production
>SourceElements :SourceElements SourceElement is evaluated as follows:

>
Could you elaborate a little more on what you are talking about? What
'spec' do you mean? JavaScript specification?

(Sometimes when you don't have a single clue what the other person is
talking about, it is better not to reply at all.) There is no JavaScript
specification. The OP is referring to the ECMAScript Specification, of
which Netscape/Mozilla.org's JavaScript is one implementation.

http://jibbering.com/faq/

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>

[Thomas 'PointedEars' Lahn]

Re: statement values

Doug Gunnoe wrote:

On Jan 3, 4:01 pm, florian.loit... @gmail.com 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?
>[...]

>
alert(eval('')) ; returns undefined as does alert(eval(';') );
>
I suppose all of this may have something to do with the fact that ';'
are not needed in javascript.
>
But alert(eval('3\n \n')) returns three also.

You miss the point, which is the evaluation of the program "3;;".

Please trim your quotes.


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>

[Doug Gunnoe]

Re: statement values

(Sometimes when you don't have a single clue what the other person is

talking about, it is better not to reply at all.) There is no JavaScript
specification.

Sometimes when all you have to say is some smart ass comment, it is
probably best not to reply at all. Of course, in your case that would
mean you would never have anything to say.

>The OP is referring to the ECMAScript Specification, of
which Netscape/Mozilla.org's JavaScript is one implementation.

You must be proud of being so smart.

I wish I was as smart as you.

But until I'm as smart as you, I'm going to refer to it as the
JavaScript specification. Because, in my lesser mind, even though
ECMAScript is the standard, it would be the JavaScript specification.
And it is also the JScript specification. And any other
implementation.

You miss the point, which is the evaluation of the program "3;;".

No. I'm right at the crux of the question, which in this case really
comes down to this part of the OP's question

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

his question comes down to, why is this ";" not treated like an empty
statement and if this is an error in the implementations . In many
languages, like C++ or Java, having just this ";" is a perfectly legal
but 'empty statement', however, it does not appear to be an 'empty
statement' for JavaScript. My answer was:

>I suppose all of this may have something to do with the fact that ';'
>are not needed in javascript.

So, in C++ I could have:

some code blah blah blah;
;

And the second ";" is a legal but empty statement and does not cause a
compile error. And the ';' is required to demarcate the end of the
statement.

In JavaScript I can do

some code blah blah blah
some more code
some more code

or,
some code blah blah blah;
some more code;
some more code;

The ';' is optional.

Care to take a stab at answering the OP's question, or would you
prefer just to make a few more Ad Homs toward me?

Specifically, what demarcates a complete legal statement in JavaScript
and what would be an empty statement in JavaScript?

I suspect that an empty line would be the equivalent of an empty
statement in JavaScript, but I am not sure.

[Thomas 'PointedEars' Lahn]

Re: statement values

Doug Gunnoe wrote:

[...] I'm going to refer to [the ECMAScript Specification] as the
JavaScript specification. Because, in my lesser mind, even though
ECMAScript is the standard, it would be the JavaScript specification.
And it is also the JScript specification. And any other
implementation.

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

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>

[Doug Gunnoe]

Re: 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?

[Doug Gunnoe]

Re: statement values

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.

[Doug Gunnoe]

Re: 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, or do you have other tricks?

[Thomas 'PointedEars' Lahn]

Re: statement values

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

[Thomas 'PointedEars' Lahn]

Re: statement values

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 bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16

[Doug Gunnoe]

Re: statement values

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.

[John G Harris]

Re: statement values

On Thu, 3 Jan 2008 at 14:01:20, in comp.lang.javas cript, 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

[John G Harris]

Re: statement values

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

<snip>

>Another question for VariableDeclara tions:
>Why does the production 'VariableDeclar ation: Identifier' and the
>production
>'VariableDecla ration: 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 VariableDeclara tion : Identifier statement during
execution gives the name that was needed. It's a pretty feeble excuse.

John
--
John Harris