Return statement and whitespace

[-TNO-]

It's not very readable, is it ?

Its much more readable than its braced counterpart IMO:

function Y (X) {
return (function(procedure) {
return X(function(arg) {
return procedure(procedure)(arg);
});
})(function(procedure) {
return X(function(arg) {
return procedure(procedure)(arg);
});
});
}

Not to mention significantly smaller.

Crockford enthusiasts will notice that leaving out the curly brackets in
this way is a bad part of JavaScript and hence will not be permitted by
JSLint.

It's not just about bracing, but about the return statement as well.
Not everyone practices or agrees with Douglas Crockford's Code
Convention choices, so I think it's a moot point. 1TBS has a popular
precedent, but is seen by a number of developers to be wasteful in as
well, especially in a web context.

 

[Thomas 'PointedEars' Lahn]

Its much more readable than its braced counterpart IMO:

function Y (X) {
return (function(procedure) {
return X(function(arg) {
return procedure(procedure)(arg);
});
})(function(procedure) {
return X(function(arg) {
return procedure(procedure)(arg);
});
});
}

I find both snippets as badly readable because of the unnecessary inline
expressions, i.e. the lack of use of variables; unnecessary, confusing reuse
of argument identifiers; and the whitespace after the `Y'. But if I ignore
that, I find the braced version better readable. The braces do help to
distinguish subroutine parts from argument lists, which are delimited by
parentheses.

Not to mention significantly smaller.

Size is heavily overrated.


PointedEars

 

[-TNO-]

I find both snippets as badly readable because of the unnecessary inline
expressions, i.e. the lack of use of variables; unnecessary, confusing reuse
of argument identifiers; and the whitespace after the `Y'.  But if I ignore
that, I find the braced version better readable.  The braces do help to
distinguish subroutine parts from argument lists, which are delimited by
parentheses.

Use of extra variables would be unnecessary since the argument names
serve this purpose well enough.
On the other points though, I'll admit the preference for I-
Expressions over M-Expressions is a matter of opinion.

Size is heavily overrated.

Maybe. Most code I've seen on the web though err's on the side of
waste and abuse of network resources (ex: The usage and/or
implementation of many Ajax libraries).

 

[Thomas 'PointedEars' Lahn]

Use of extra variables would be unnecessary since the argument names
serve this purpose well enough.

It would be easier readable if local variables would be assigned the
function expressions or expression closures (here: the former):

function y(x)
{
var f = function(procedure) {
return x(function(arg) {
return procedure(procedure)(arg);
});
};

var g = function(procedure) {
return x(function(arg) {
return procedure(procedure)(arg);
});
};

return f(g);
}

Indeed, this example shows that code reuse, which is more efficient, is
possible with variables, as f and g are equivalent. However, I was never in
need of any such pattern in about 12 years of ECMAScript scripting now, so
this discussion is rather academic to me.

On the other points though, I'll admit the preference for I-
Expressions over M-Expressions is a matter of opinion.

Sorry, my Web search did not yield results for `I-Expressions'.
Please elaborate.

Maybe. Most code I've seen on the web though err's on the side of
waste and abuse of network resources (ex: The usage and/or
implementation of many Ajax libraries).

True, however a few bytes more, as here, clearly do not count with any
reasonable Internet connection today (and even less on the local
filesystem). And the code will undoubtedly be in need of change more often
than being originally written or downloaded (thus the "do more, write less"
jQuery mantra is complete nonsense).


PointedEars

 

[John G Harris]

ISTM otherwise. It is treating the "function A()" as needing a
following compound statement, and allowing a simple statement "alert(1)"
where a compound one is expected. The combination is wrong.

<snip>

On second thoughts it's more likely that the function body is replaced
by
expression ;
After all, it's supposed to represent the operand of a return statement.

I had a crawl round the Mozilla web site but couldn't find any
definition of this new function construct. Why am I not surprised ?

John

 

[-TNO-]

Sorry, my Web search did not yield results for `I-Expressions'.
Please elaborate.

Very roughly speaking, an I-Expression is the use of indentation to
implicitly represent parenthesis/braces. It's not quite correct for me
to refer to a JavaScript expression closure as an I-Expression, but I
figured it was the quickest way to express the syntactic style
difference. I apologize for not being clearer, I was feeling lazy.

Ultimately, I just didn't see John G Harris's argument against
expression closures. People don't seem to complain too much about an
inline conditional:

if(foo){
bar
} else {
baz
}

vs.

foo ? bar : baz;

Maybe my choice of an example could have been better than the Y-
Combinator:

var factorial = function(n) (n == 0 || n == 1) ? 1 : n * factorial
(n-1);

Of course, I'm probably just a sucker for succinct code.

 

[John G Harris]

On Tue, 28 Jul 2009 at 14:22:45, in comp.lang.javascript, -TNO- wrote:

Not everyone practices or agrees with Douglas Crockford's Code
Convention choices,

<snip>

Beware! That will upset Jorge.

John

 

[-TNO-]

I had a crawl round the Mozilla web site but couldn't find any
definition of this new function construct. Why am I not surprised ?

Your search-Fu needs more cowbell. I posted this link earlier in the
discussion:

https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Tue, 28 Jul 2009 17:43:56, Dr J R Stockton

Consider : the expression (0.007).toFixed(2) gives 0.00 in JScript.

QUERY : is it now reasonably safe to call toFixed unconditionally, it is
an existence test needed still?

Q ?

Furthermore, the range of number magnitudes for which JScript
X.toFixed(0) wr0ngly gives 0 is not 0.50 to 0.94 as previously stated,
but 0.50 t0 0.95. Those numbers scale by /10 as the argument is
incremented.

JScript +(X.toFixed(0)) also differs from Math.round(X) for the negative
half-integers (as required by the standards).

Page <URL:http://www.merlyn.demon.co.uk/js-rndg1.htm> is updated in that
part, with demonstrations.


It occurs to me that, while it would be too long for the FAQ itself, it
might be useful to have in the Notes one or more pages which demonstrate
by code such variations between browsers, as in that page and in
<URL:http://www.merlyn.demon.co.uk/js-datex.htm>. With code showing the
effect in the user's current browser, such a document can support all
browsers ; and, if differences are reported, one knows what the tests
were.

 

[John G Harris]

Your search-Fu needs more cowbell. I posted this link earlier in the
discussion:

https://developer.mozilla.org/en/New_in_JavaScript_1.8#Expression_closures

And I looked in the Mozilla 'Core JavaScript 1.5 Reference' to see that

function f() { return 42; }

is legal, but nowhere could I find out if

function f() return 42;

is legal, least of all in the 'New in JavaScript 1.8' page you point us
towards.

Worse, I can't even find out if shorthand function declarations are
allowed.

John

 

[-TNO-]

And I looked in the Mozilla 'Core JavaScript 1.5 Reference' to see that

  function f() { return 42; }

is legal, but nowhere could I find out if

  function f() return 42;

is legal, least of all in the 'New in JavaScript 1.8' page you point us
towards.

Worse, I can't even find out if shorthand function declarations are
allowed.

Quoted from the page I referenced:

"This syntax allows you to leave off the braces and 'return' statement
- making them implicit. There is no added benefit to writing code in
this manner, other than having it be syntactically shorter."

Which reads to me to mean that the following are equivalent:

function f(){return 42};

function f() 42;

Typing these into the Fx browser console will show you that both are
valid syntax. Typing the following though into the browsers console
though will throw a syntax error:

function f() return 42;

We should be able to see some more in depth documentation on this
soon: http://wiki.ecmascript.org/doku.php?id=strawman:strawman

With trivial code like this, its much faster to run it through a
command line, then to dig around in often outdated documentation.

 

[John G Harris]

On Fri, 31 Jul 2009 at 15:05:55, in comp.lang.javascript, -TNO- wrote:

With trivial code like this, its much faster to run it through a
command line, then to dig around in often outdated documentation.

Never say that at a job interview.

John

 

[John G Harris]

And I looked in the Mozilla 'Core JavaScript 1.5 Reference' to see that

function f() { return 42; }

is legal, but nowhere could I find out if

function f() return 42;

is legal, least of all in the 'New in JavaScript 1.8' page you point us
towards.

Worse, I can't even find out if shorthand function declarations are
allowed.

Nor can I find out if

function f() ;

is legal, and if it is then nor can I find out if

function f()
alert (42)

has one implied semicolon or two. If it has two then Crockford will
surely classify it as being one of the 'awful parts' of JavaScript.

John

 

[-TNO-]

Nor can I find out if

  function f() ;

is legal, and if it is then nor can I find out if

  function f()
  alert (42)

has one implied semicolon or two. If it has two then Crockford will
surely classify it as being one of the 'awful parts' of JavaScript.

Testing this in the browser command line would have been faster than
asking the question

function f();

Will return a syntax error, as it is expecting an expression following
the parenthesis.

function f()
alert (42)

This is the same as writing:

function f() alert (42);

So its valid. I posted a code example that used this very same pattern
earlier. (The Y-Combinator).

 

[-TNO-]

On Fri, 31 Jul 2009 at 15:05:55, in comp.lang.javascript, -TNO- wrote:



Never say that at a job interview.

  John

Why not? If you don't claim to have knowledge you really don't have at
that interview, I bet it would be a moot point.

 

[John G Harris]

On Aug 2, 4:02 am, John G Harris <[email protected]> wrote:

function f();

Will return a syntax error, as it is expecting an expression following
the parenthesis.

<snip>

Says who ? What if you want to return undefined ?

John

 

[-TNO-]

Says who ?

The implementation says who.

What if you want to return undefined?

function f() undefined;

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
rlyn.invalid>, Tue, 28 Jul 2009 17:43:56, Dr J R Stockton


Q ?

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?

1.1255.toFixed(3);

IE7, some Safari versions:
1.126

Others:
1.125

Furthermore, the range of number magnitudes for which JScript
X.toFixed(0) wr0ngly gives 0 is not 0.50 to 0.94 as previously stated,

Is it? I see 0.95.toFixed(0)

IE7: 1

but 0.50 t0 0.95. Those numbers scale by /10 as the argument is
incremented.

JScript +(X.toFixed(0)) also differs from Math.round(X) for the negative
half-integers (as required by the standards).

JScript only, or implementations in general?

Page <URL:http://www.merlyn.demon.co.uk/js-rndg1.htm> is updated in that
part, with demonstrations.


It occurs to me that, while it would be too long for the FAQ itself, it
might be useful to have in the Notes one or more pages which demonstrate
by code such variations between browsers, as in that page and in
<URL:http://www.merlyn.demon.co.uk/js-datex.htm>. With code showing the
effect in the user's current browser, such a document can support all
browsers ; and, if differences are reported, one knows what the tests
were.

Automated Unit Tests for standards are something I've wanted to do but
have not done. This could be done for ECMAScript and would be very
useful for the DOM.

It came up a w3c mailing list, but didn't get much follow up.
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0035.html

My hesitations to setting up testing for the w3c is that it takes
effort. I don't want to abet those w3c members who would write tests for
what I think are very bad ideas. I think they would do this, and that it
could result in those bad ideas going into the latest build of whatever
browser, just to get a higher "compatibility rank" of passing more
tests. I do not endorse HTML 5. I don't want w3c members to use their
position to win arguments and write tests for bad ideas.

So, it is still a good idea, and I think it should be something that
members of this NG could start. That still takes effort, but instead of
testing the what wishlist, it can focus on existing w3c TRs and ECMAScript.

Garrett

 

[RobG]

The implementation says who.


function f() undefined;

<sarcasm>
Which is clearly shorter, more readable and easily maintained than:

function f(){}

</sarcasm>

For the sake of two curly braces, the loss of clarity is simply not
worth it, even if it is shorter. Who thinks up this crap? Do they sit
around all day thinking "what obscure traps can we make for
programmers today"?

Don't these guys have editors with auto-complete?

 

[Thomas 'PointedEars' Lahn]

<sarcasm>
Which is clearly shorter, more readable and easily maintained than:

function f(){}

</sarcasm>

For the sake of two curly braces, the loss of clarity is simply not
worth it, even if it is shorter. Who thinks up this crap? Do they sit
around all day thinking "what obscure traps can we make for
programmers today"?

I do not think expression closures are a bad thing per se (they remind me
of Python's lambda expressions, which are quite useful and readable¹).
But as with all things, use them wisely.

Don't these guys have editors with auto-complete?

Non sequitur. It is better for the programming language to provide
syntactic sugar than for developers needing to invent it.


PointedEars
___________
¹ as in map(lambda foo: foo['bar'], list_of_dicts)