From: Johannes Baagoe on
Garrett Smith :
> Johannes Baagoe :
>>> nick :

>>>> "Some JavaScript engines, not including SpiderMonkey, incorrectly
>>>> treat any function expression with a name as a function definition"

>> In a sort of lame defence (why on earth am I trying to excuse
>> Microsoft?),

> If you're asking me to guess, I would say that you have probably
> mistaken "function definition" with "function declaration".

I hope not. I talk about a function expression with a name. As I
understand it, that is a realisation of

FunctionExpression :
function Identifier opt ( FormalParameterList opt ) { FunctionBody }

in which the optional Identifier (the "name") exists.

> I suggest you to and read the ECMA-262 specification for "Function
> Definition".

I have, just in case, but I didn't need to: my memory was quite accurate.

--
Johannes
From: Johannes Baagoe on
Stefan Weiss :

> Didn't you say (in a different thread) that you "quite liked" Jorge's
> loop() function? That's a named function expression, too. It doesn't
> have to be - you could just call loop() separately from its definition -
> but the way you're using it on
>
> http://baagoe.com/en/RandomMusings/javascript/time.js
>
> it's still a named function expression.

Touché. You are right about that one. I shall correct the matter forthwith.

> Do you deserve a terrible fate now? ;-)

Well, yes: having to confess that my behaviour does not always match my
words :) And publicly, too.

--
Johannes
From: Garrett Smith on
Johannes Baagoe wrote:
> Garrett Smith :
>> Johannes Baagoe :
>>>> nick :
>
>>>>> "Some JavaScript engines, not including SpiderMonkey, incorrectly
>>>>> treat any function expression with a name as a function definition"
>
>>> In a sort of lame defence (why on earth am I trying to excuse
>>> Microsoft?),
>
>> If you're asking me to guess, I would say that you have probably
>> mistaken "function definition" with "function declaration".
>
> I hope not. I talk about a function expression with a name. As I
> understand it, that is a realisation of
>
> FunctionExpression :
> function Identifier opt ( FormalParameterList opt ) { FunctionBody }
>
> in which the optional Identifier (the "name") exists.
>
>> I suggest you to and read the ECMA-262 specification for "Function
>> Definition".
>
> I have, just in case, but I didn't need to: my memory was quite accurate.
>

Then what is wrong with an implementation treating a FunctionExpression
as a Function Definition? And if the answer is nothing (which is the
correct answer) then why insist Microsoft got that wrong?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Stefan Weiss on
On 20/04/10 21:12, Johannes Baagoe wrote:
> Stefan Weiss :
>> and when you want to recurse from inside a function expression.
>
> What is wrong with
>
> var fact = function(n) {
> if (n > 0) {
> return n * fact(n - 1);
> } else {
> return 1;
> }
> };
>
> ?

It works, of course, but it makes the recursion dependent on a
(potentially unrelated) variable from an outer scope. I don't think the
implementation of a function should need to care about which variable it
will be assigned to. And then there are the "self-executing" functions
from your original examples, which run before their result is assigned
to a variable:

var foo = (function () {
// what if I want to recurse here?
})();

BTW, I prefer this style of parenthesis placement, but I think both are
fine as long as the intention is clear.


--
stefan
From: Johannes Baagoe on
Stefan Weiss :
>Johannes Baagoe :

>> var fact = function(n) {
>> if (n > 0) {
>> return n * fact(n - 1);
>> } else {
>> return 1;
>> }
>> };

> It works, of course, but it makes the recursion dependent on a
> (potentially unrelated) variable from an outer scope. I don't think the
> implementation of a function should need to care about which variable it
> will be assigned to.

Good point. One can enclose them in yet another function, though,
but I'm not sure that makes things clearer.

> And then there are the "self-executing" functions from your original
> examples, which run before their result is assigned to a variable:

> var foo = (function () {
> // what if I want to recurse here?
> })();

You are right, I can't. If I want to define 21! inline using neither
named function expressions nor function declarations, the best I have
come up with is

((function() {
return fact = function(n) {return n > 0 ? n * fact(n - 1) : 1;};
}())(21));

which is hardly a model of legibility.

So there may legitimate uses for named function expressions after all.
The trouble is that their formal definition is so badly ambiguous
that I immediately object on aesthetic if not on sound theoretical
grounds, but I admit that if the implementations always get it right,
it becomes little more than a matter of taste. (Of course, if MDC
doesn't lie, some implementations *don't* get it right, which gives
rather more weight to my theoretical pretexts.)

--
Johannes