Prev: seethis VERY DIFFERENT
Next: regex help?
From: kangax on 5 Dec 2009 20:17
Dmitry A. Soshnikov wrote:
> On Dec 4, 9:04 pm, kangax <kan...(a)gmail.com> wrote:
>
> [...]
>
>> Technically, there are no function statements in ES5. Function
>> declarations are still /SourceElement/'s and so are only allowed in
>> /Program/ and /FunctionBody/.
>>
>> What happens to "Function Statements" is still *not formally specified*.
>> As a matter of fact, if you look at Chapter 12, you can see this note:
>>
>> "NOTE Several widely used implementations of ECMAScript are known to
>> support the use of FunctionDeclaration as a Statement. However there are
>> significant and irreconcilable variations among the implementations in
>> the semantics applied to such FunctionDeclarations. Because of these
>> irreconcilable difference, the use of a FunctionDeclaration as a
>> Statement results in code that is not reliably portable among
>> implementations. It is recommended that ECMAScript implementations
>> either disallow this usage of FunctionDeclaration or issue a warning
>> when such a usage is encountered. Future editions of ECMAScript may
>> define alternative portable means for declaring functions in a Statement
>> context."
>>
>
> Yeah, already discussed regarding ECMA-262-3. And nevertheless,
> implementation of Spidermonkey (and other newer *monkeys) still seems
> to me more logical (e.g. for if-else statements) regardless
> specification. I don't see the big sense in words they say "an
> ExpressionStatement cannot start with the `function` keyword because
> that might make it ambiguous with a FunctionDeclaration"? If it's in

That's because it would be useless (as it is specified now). Let's
assume Function Expression is allowed in statement:

if (true) {
function(){}
}

or:

if (true) {
function f(){}
}

You see what happens?

We end up with essentially "dead" code: Identifier (if present) is never
made available to the outer scope (as per function expression rules);
function is instantiated and can immediately be garbage collected. ;)

What's the point? Surely, it's better to disallow this kind of scenario
earlier � on a syntactic level.

> statement position let's treat is as special FD which won't be created
> on entering the context, but in runtime like FE and let's call it
> Function Statement (FS). I thought ECMA-262-5 should borrow this
> Spidermonkey's `FS`s. But no, they again have restriction for FD-style
> function's in statements and I don't see the useful goal from it. ;)

I suppose there are back-compat concerns, as some clueless code on the
web can rely on functions in statements, and behavior opposite to that
of SpiderMonkey's (i.e. function statements are treated as function
declarations, independent of whether statements they are contained
within are executed):

if (true) {
function f(){ return 1; }
}
else {
// code relies on `f` referencing this, second, function
function f(){ return 2; }
}

If ES5 were to introduce SpiderMonkey -like function statements, we
would certainly end up with some breakage (unless it would be part of
strict mode).

Oh, and by the way, you might be interested in this es-discuss thread �
https://mail.mozilla.org/pipermail/es-discuss/2007-March/003920.html

--
kangax
From: kangax on 5 Dec 2009 20:23
Lasse Reichstein Nielsen wrote:
> "Dmitry A. Soshnikov" <dmitry.soshnikov(a)gmail.com> writes:
>
>> Yeah, already discussed regarding ECMA-262-3. And nevertheless,
>> implementation of Spidermonkey (and other newer *monkeys) still seems
>> to me more logical (e.g. for if-else statements) regardless
>> specification. I don't see the big sense in words they say "an
>> ExpressionStatement cannot start with the `function` keyword because
>> that might make it ambiguous with a FunctionDeclaration"? If it's in
>> statement position let's treat is as special FD which won't be created
>> on entering the context, but in runtime like FE and let's call it
>> Function Statement (FS).
>
> What would be the scope of the name introduced by this function
> statement?
>
> Would it, essentially, be a shorthand of:
> var name = function name(args) { body };

Yep.

> or
> var name = function(args) { body };

Well, here we loose Identifier (useful for inspection purposes), so I'd
rather it be a first version.

> If so, why not use that?

It wouldn't be as compact and clean (just look at all those repeating
identifiers):

var foo;
if (true) {
foo = function foo(){};
}
else {
foo = function foo(){};
}

to:

if (true) {
function foo(){};
}
else {
function foo(){};
}

--
kangax
From: Dmitry A. Soshnikov on 6 Dec 2009 06:45
On Dec 6, 4:17 am, kangax <kan...(a)gmail.com> wrote:
> Dmitry A. Soshnikov wrote:
> > On Dec 4, 9:04 pm, kangax <kan...(a)gmail.com> wrote:
>
> > [...]
>
> >> Technically, there are no function statements in ES5. Function
> >> declarations are still /SourceElement/'s and so are only allowed in
> >> /Program/ and /FunctionBody/.
>
> >> What happens to "Function Statements" is still *not formally specified*.
> >> As a matter of fact, if you look at Chapter 12, you can see this note:
>
> >> "NOTE      Several widely used implementations of ECMAScript are known to
> >> support the use of FunctionDeclaration as a Statement. However there are
> >> significant and irreconcilable variations among the implementations in
> >> the semantics applied to such FunctionDeclarations. Because of these
> >> irreconcilable difference, the use of a FunctionDeclaration as a
> >> Statement results in code that is not reliably portable among
> >> implementations. It is recommended that ECMAScript implementations
> >> either disallow this usage of FunctionDeclaration or issue a warning
> >> when such a usage is encountered. Future editions of ECMAScript may
> >> define alternative portable means for declaring functions in a Statement
> >> context."
>
> > Yeah, already discussed regarding ECMA-262-3. And nevertheless,
> > implementation of Spidermonkey (and other newer *monkeys) still seems
> > to me more logical (e.g. for if-else statements) regardless
> > specification. I don't see the big sense in words they say "an
> > ExpressionStatement cannot start with the `function` keyword because
> > that might make it ambiguous with a FunctionDeclaration"? If it's in
>
> That's because it would be useless (as it is specified now).Let's
> assume Function Expression is allowed in statement:
>
>   if (true) {
>     function(){}
>   }
>
> or:
>
>   if (true) {
>     function f(){}
>   }
>
> You see what happens?
>
> We end up with essentially "dead" code: Identifier (if present) is never
> made available to the outer scope (as per function expression rules);
> function is instantiated and can immediately be garbage collected. ;)
>
> What's the point? Surely, it's better to disallow this kind of scenario
> earlier — on a syntactic level.
>

But it should be treated as `FE` for not to be useless. It should be
treated as a special form, sort of combination of `FD + FE`, which
means: affecting on the scope by the *same* rules as `var` and `FD`,
but creating in runtime just like `FE`. Maybe it won't be so useful
(or even useless) in some statements blocks, but e.g. in `if-else`
blocks it's very useful. And in discussion of the link you gave
bellow, I agree wit Igor Bukanov and Brendan Eich.

So, the main reason is not "it's useless", but "because that might
make it ambiguous with a FunctionDeclaration", which means scanner/
parser can't resolve with what kind of object it deals: with FD which
should be created on entering the context (what most implementations
do) or FE which should be created in runtime.

It's absolutely should be same as for:

function test() {}();

Here scanner/parser can't determinate what's this: FD or FE, so it
truly throws an exception. Just then, when we surround this case with
grouping operator (as one of the ways to transform it to `FE`),
scanner knows that it's `FE`:

(function test() {})();

Meanwhile, in this case, it knows it without our manually instruction
(with grouping operator):

var o = {
bar: function () {
return 'test';
}();
};

alert(o.bar); // "test"

To make it easier, they wrote: `[lookahead ∉ {{, function}]
Expression ;` - and that's the reason, but not "that's useless". And
Spidermonkey still got its right (by section 16) and make extension -
`FS` (but you sure know it all yourself).

/ds
From: Dmitry A. Soshnikov on 6 Dec 2009 06:50
On Dec 6, 2:45 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:

[...]

>
> But it should be treated as `FE` for not to be useless.
^^^^^^^^^^^
main typo: should NOT be treated as `FE` ;)
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: seethis VERY DIFFERENT
Next: regex help?