Return statement and whitespace

[John G Harris]

The implementation says who.


function f() undefined;

The Mozilla 'New in JavaScript 1.8' web page says that

"This syntax allows you to leave off the braces and 'return'
statement - making them implicit."

Now

function f() { return ; }

is legal, so according to that web page

function f() ;

should also be legal as all I have done is to leave off the curly
brackets and 'return' keyword.

Face it, there's a bug in Firefox. Someone should report it.

Someone should also tell the Mozilla people that there's a not so subtle
difference between a keyword and a statement.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sun, 2 Aug 2009 20:08:44, John G Harris

<snip>

Says who ? What if you want to return undefined ?

Try function f() {} ;

 

[-TNO-]

The Mozilla 'New in JavaScript 1.8' web page says that

   "This syntax allows you to leave off the braces and 'return'
    statement - making them implicit."

Now

   function f() { return ; }

is legal, so according to that web page

   function f() ;

should also be legal as all I have done is to leave off the curly
brackets and 'return' keyword.

Face it, there's a bug in Firefox. Someone should report it.

Someone should also tell the Mozilla people that there's a not so subtle
difference between a keyword and a statement.

I forwarded the question to es-discuss, and Brendan Eich privileged me
with a response:

https://mail.mozilla.org/pipermail/es-discuss/2009-August/009692.html

 

[John G Harris]

I forwarded the question to es-discuss, and Brendan Eich privileged me
with a response:

https://mail.mozilla.org/pipermail/es-discuss/2009-August/009692.html

Interesting. They've written the code, released the product, now they're
asking for volunteers to work out what they should have done. Sheesh!

John

 

[-TNO-]

Interesting. They've written the code, released the product, now they're
asking for volunteers to work out what they should have done. Sheesh!

There is no shame in innovation and experimentation on the advancement
of the language. You can't build everything perfect the first time.
Sometimes these things have to released in the wild to see what real
world code does with it. Take for example: https://bugzilla.mozilla.org/show_bug.cgi?id=366941

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sun, 2 Aug 2009 23:27:06, Garrett Smith


You have not answered the explicit question - is it safe to call
toFixed? I expressed no interest in whether it is safe to believe the
result of the call. I was only interested in whether any reasonably
current browsers would in effect say "toFixed? never heard of it".

I'm not sure that toFixed is all that useful, due to rounding issues. I
mean, it is not something that could be used for money, right?

Money is not the only application in the world.

Money calculations should be done in integer arithmetic; cents for
ordinary work, M€ for eurocrats. <FAQENTRY> The FAQ should be modified
to say that.

Jibbering seems down.
A mirror is needed.

1.1255.toFixed(3);

IE7, some Safari versions:
1.126

Others:
1.125

1.1255 cannot be represented exactly in a Double. There is no certainty
that +"1.1255" gives the same IEEE Double in all browsers, whatever the
Standard may say. And there is likewise no certainty that each of those
IEEE Doubles will, even in a carefully-written browser, will give the
same result on any conversion to string.

On the same lines : It was settled that one euro would be equal to
exactly 0.787564 punts. That did not mean that the Bank could take Tim
O'Shea & Co's balance of, say, IEP 1234567.89, as an IEEE Double, divide
it by 0.787564, and rewrite it as EUR 1567577.86; the required
arithmetic was expressed exactly, including rounding, in decimal. I
suspect they'd have ended up with EUR 1567580, but that is a guess.

Is it? I see 0.95.toFixed(0)

IE7: 1

I wrote 0.50 to 0.95, carefully without saying whether the ends of the
range were to be included. In fact, as you must know, 0.95 cannot be
represented exactly by an IEEE Double.

JScript :
0.94999999999999990.toFixed(0) -> 0
0.94999999999999991.toFixed(0) -> 1


Since the limit is 0.95 not 0.94, I suspect that the effect is not a bug
as such but a foolishly-incorporated "feature".

JScript only, or implementations in general?

I was not then saying. I now say that is browser-dependent; there seems
to be a misinterpretation of the standard in at least one case. Work is
in hand.

and is more updated.


Tests comparing the numerical values of the strings given by
toExponential & toPrecision with the results of my own conversions in 5
browsers, for random inputs have shown no problems. Testing the same
values with toFixed in 4 browsers showed no problems. There was one
case where the input was very close to half-way between the two adjacent
possible output values obtained.

Those tests need to be run for longer.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sun, 2 Aug 2009 23:27:06, Garrett Smith


You have not answered the explicit question - is it safe to call
toFixed? I expressed no interest in whether it is safe to believe the
result of the call. I was only interested in whether any reasonably
current browsers would in effect say "toFixed? never heard of it".

I'm not sure that toFixed is all that useful, due to rounding issues. I
mean, it is not something that could be used for money, right?

Money is not the only application in the world.

Money calculations should be done in integer arithmetic; cents for
ordinary work, M€ for eurocrats. <FAQENTRY> The FAQ should be modified
to say that.

Jibbering seems down.
A mirror is needed.

1.1255.toFixed(3);

IE7, some Safari versions:
1.126

Others:
1.125

1.1255 cannot be represented exactly in a Double. There is no certainty
that +"1.1255" gives the same IEEE Double in all browsers, whatever the
Standard may say. And there is likewise no certainty that each of those
IEEE Doubles will, even in a carefully-written browser, will give the
same result on any conversion to string.

On the same lines : It was settled that one euro would be equal to
exactly 0.787564 punts. That did not mean that the Bank could take Tim
O'Shea & Co's balance of, say, IEP 1234567.89, as an IEEE Double, divide
it by 0.787564, and rewrite it as EUR 1567577.86; the required
arithmetic was expressed exactly, including rounding, in decimal. I
suspect they'd have ended up with EUR 1567580, but that is a guess.

Is it? I see 0.95.toFixed(0)

IE7: 1

I wrote 0.50 to 0.95, carefully without saying whether the ends of the
range were to be included. In fact, as you must know, 0.95 cannot be
represented exactly by an IEEE Double.

JScript :
0.94999999999999990.toFixed(0) -> 0
0.94999999999999991.toFixed(0) -> 1

JScript only, or implementations in general?

I was not then saying. I now say that is browser-dependent; there seems
to be a misinterpretation of the standard in at least one case. Work is
in hand. ... For X.toFixed(0), where X is a half-integer, Opera 9.64
does Banker's Rounding, contrary to ISO/IEC 16262 15.7.4.5 #10.
Reported. Other browsers correctly round away from zero.


and is more updated.


Tests comparing the numerical values of the strings given by
toExponential & toPrecision with the results of my own conversions in 5
browsers, for random inputs have shown no problems. Testing the same
values with toFixed in 4 browsers showed no problems. There was one
case where the input was very close to half-way between the two adjacent
possible output values obtained.

Those tests need to be run for longer.

 

[John G Harris]

There is no shame in innovation and experimentation on the advancement
of the language. You can't build everything perfect the first time.
Sometimes these things have to released in the wild to see what real
world code does with it. Take for example: https://bugzilla.mozilla.org
/show_bug.cgi?id=366941

How the hell can anyone try it out if they aren't told what they've been
given to try ?

John

 

[-TNO-]

How the hell can anyone try it out if they aren't told what they've been
given to try ?

I'm not sure what you're specifically referring to here. Can you
define "it"?

 

[John G Harris]

I'm not sure what you're specifically referring to here. Can you
define "it"?

Why, 'it' is any feature that's new in Firefox, of course. Did your 'it'
mean anything different ?

John

 

[-TNO-]

Why, 'it' is any feature that's new in Firefox, of course. Did your 'it'
mean anything different ?

I was being specific, which is why your generic statement confused me.
So now that I know what you meant:

How the hell can anyone try it out if they aren't told what they've been
given to try ?

Every time you upgrade the browser you're told:
http://www.mozilla.com/en-US/firefox/releases/

Not to mention the variety of Mozilla blogs available.:
http://hacks.mozilla.org/
http://weblogs.mozillazine.org/

 

[John G Harris]

I was being specific, which is why your generic statement confused me.
So now that I know what you meant:


Every time you upgrade the browser you're told:
http://www.mozilla.com/en-US/firefox/releases/

Not to mention the variety of Mozilla blogs available.:
http://hacks.mozilla.org/
http://weblogs.mozillazine.org/

Were we told if

function f() ;

is legal or not, or that the syntax rule is not

function Identifier|opt ( FormalParameterList|opt ) expression ;

John

 

[-TNO-]

Were we told if

  function f() ;

is legal or not, or that the syntax rule is not

  function Identifier|opt ( FormalParameterList|opt ) expression ;

Brendan Eich's explanation was clear. This is the rule that defines
what is and is not legal:

ExpressionClosure:
function Identifier[opt] ( FormalParameterList[opt] )
AssignmentExpression

 

[John G Harris]

Were we told if

  function f() ;

is legal or not, or that the syntax rule is not

  function Identifier|opt ( FormalParameterList|opt ) expression ;

Brendan Eich's explanation was clear. This is the rule that defines
what is and is not legal:

ExpressionClosure:
function Identifier[opt] ( FormalParameterList[opt] )
AssignmentExpression

This rule was revealed on Mon Aug 3 10:09:48 PDT 2009 as a byproduct of
this thread. Expressions closures were announced to be in Firefox in Oct
2008 or earlier.

What explanation was 'clear' last October ?

Also Eich says "The production is essentially" ... . How 'clear' is that
supposed to be ?

John

 

[-TNO-]

This rule was revealed on Mon Aug 3 10:09:48 PDT 2009 as a byproduct of
this thread.

Absence of evidence is not evidence of absence. Just because I
happened to ask the question directly in relationship to your edge
case code earlier, does not mean no one else has in some other
discussion.

Expressions closures were announced to be in Firefox in Oct 2008 or earlier. What explanation was 'clear' last October ?

I've found documentation for this construct going back to 2006 (For
example: http://wiki.ecmascript.org/doku.php?id=proposals:expression_closures,
and its related implementation bug in Fx: https://bugzilla.mozilla.org/show_bug.cgi?id=381113).
Are you questioning why John/Jane Doe of the open source community
didn't update the Wiki with a grammar production back in Oct 2008,
maybe you should ask him/her? This line of thinking is hardly
productive anbd I don't see the point. What is it you're still
confused about? It's starting to sound like you're looking for
something to complain about now.

Also Eich says "The production is essentially" ... . How 'clear' is that
supposed to be ?

What are you still confused about?

 

[John G Harris]

On Aug 7, 1:39 pm, John G Harris <[email protected]> wrote:

Are you questioning why John/Jane Doe of the open source community
didn't update the Wiki with a grammar production back in Oct 2008,
maybe you should ask him/her? This line of thinking is hardly
productive anbd I don't see the point. What is it you're still
confused about? It's starting to sound like you're looking for
something to complain about now.

I'm not confused. You keep telling us to find out the rule by trying
various bits of code and seeing if it works. That's well known to be a
recipe for future problems and isn't appropriate in professional design
work.

Then you say the information is available, first by pointing to
something that's an incomplete outline, then to something that's just
been written, then to something that is an inconclusive series of
ramblings. I'm pointing out that the information isn't easy to find, and
maybe hasn't been published yet.

By implication, I'm also saying that it's a pretty poor show.

What are you still confused about?

'essentially' means 'like, but not exactly like'. I'm not confused. I'm
just pointing out that we haven't been told the truth yet. At least, not
via the Firefox web site.
John

 

[-TNO-]

I'm not confused. You keep telling us to find out the rule by trying
various bits of code and seeing if it works.

And yet you'll waste countless amount of time asking for the answer to
a problem that you could have discovered in seconds in a command line.
It's trivial code snippets.

That's well known to be a
recipe for future problems and isn't appropriate in professional design
work.

This is an experimental, non-standardized language extension . Are
you building a professional application using relying upon it? Sounds
quite hypocritical.

Then you say the information is available, first by pointing to
something that's an incomplete outline

Incomplete in relationship to an edge case you presented

then to something that's just
been written,

To clarify your edge case....

then to something that is an inconclusive series of
ramblings.

I'm sorry if the production grammar is above your head, I don't have
the patience to explain further.

I'm pointing out that the information isn't easy to find, and
maybe hasn't been published yet.

The references I gave you from the standards sight are the most up to
date you will find. Anything beyond that is better asked from the
language designers as I had done for you.

By implication, I'm also saying that it's a pretty poor show.

And yet you'll complain about it to everyone but the right people? Not
very productive

It's an experimental language extension, and has a good probability of
being a moving target before implementation. I clear enough to answer
your question, and clear enough to implement it yourself.

'essentially' means 'like, but not exactly like'. I'm not confused. I'm
just pointing out that we haven't been told the truth yet. At least, not
via the Firefox web site.

You're implying someone is lying and/or intentionally keeping you in
the dark, which they clearly are not.

 

[-TNO-]

The references I gave you from the standards sight are the most up to
date you will find. Anything beyond that is better asked from the
language designers as I had done for you.

s/sight/site

 

[John G Harris]

On Sat, 8 Aug 2009 at 23:39:05, in comp.lang.javascript, -TNO- wrote:

It's an experimental language extension, and has a good probability of
being a moving target before implementation.

<snip>

Something for John Stockton to ponder upon.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sat, 8 Aug 2009 19:13:39, John G Harris

I'm not confused. You keep telling us to find out the rule by trying
various bits of code and seeing if it works. That's well known to be a
recipe for future problems and isn't appropriate in professional design
work.

Finding out what happens on actual systems seems essential for
professional implementation.

One should use only that which *both* ought to work *and* actually does
work.

If something does not work in one of, say, IE & FF, then it's not
appropriate for Web use, even if one thinks the standard says that it
should work.

And I can test, say, for (J=1 ; J<9) J++ in the current browser
in less time than it takes to open the ECMA PDF, let alone find the
right part of it.