Function declarations in statements

liorean liorean at gmail.com
Fri Mar 16 20:07:12 PDT 2007


On 17/03/07, Yuh-Ruey Chen <maian330 at gmail.com> wrote:
> Here is something I wrote some time ago on this topic:
> http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions#Function_constructor_vs._function_declaration_vs._function_expression
>
> However, it's pretty specific to SpiderMonkey and I didn't fully test
> out other ES3 implementations. It is indeed a mess. I didn't even cover
> variable bindings like you have.

I think the current situation can be summed up like this:

- JScript compile time initialises FunDecl, FunExpr and FunDeclInSmt,
binding the identifier in all cases in the surrounding scope (spec
violation).
- Opera linear_b compile time initialises FunDecl, FunExpr and
FunDeclInSmt, binding the identifier of FunExpr in the contained
scope.
- SpiderMonkey compile time initialises FunDecl, FunExpr. FunDeclInSmt
is run time initilised. The identifier in FunExpr is bound in the
contained scope. (FunDeclInSmt is still bound in surrounding scope...)
- JavaScriptCore Compile time initialises FunDecl, FunExpr.
FunDeclInSmt varies between compile time, run time and parse error
depending on which statement type, exact syntax used and
JavaScriptCore version. The identifier in FunExpr is bound in the
contained scope since this syntax was added in Safari 1.3, before that
it caused a parse error.

More exactly, testing in Safari 1.3 because that's what I have on this comp:

Run time initialised:
- with-smt
- if..else-smt
- while-smt
- for-smt
- for..in-smt
Those above UNDER ONE CONDITION: the FunDecl is nested in a block-smt.
- try..catch

Compile time initialised:
- labelled..block..break-smt

Parse error:
- with-smt
- if..else-smt
- while-smt
- for-smt
- for..in-smt
Those above if  FunDecl IS NOT nested in a block-smt.


> Unfortunately, I don't think we can force function declarations to be
> "initialized run-time" since it's a backwards incompatible change.

In what way is it backwards incompatible?

It's a syntax error in ES3. Function declarations are only allowed in
source elements context. Function expressions are not allowed in
expression statements (indeed, they would be useless there, since the
only way you can get a reference to a function expression is by it's
return value. The name is bound in local scope only.). Thus we're
speaking of defining behaviour for an area that was not covered in any
way by ES3.
All you will be doing is adding a missing a feature, you won't be
breaking any ES3 code. And I think if you spider the web, there will
be very few, or none, scripts relying on either the SpiderMonkey or
the JScript behaviour.

Further, Microsoft will have to split up their currently unified
handling of all types of functions in JScript if they want to fully
comply to ES3 in this. Changing the FunDeclInSmt handling would be
easy to do at the same time.
-- 
David "liorean" Andersson


More information about the Es4-discuss mailing list