Question about joined function object of ECMA-262 3rd edition

Lars T Hansen lth at
Tue Jul 31 04:52:02 PDT 2007

On 7/30/07, P T Withington <ptw at> wrote:

> So, what the spec meant to say is:  If the compiler writer can think
> of an optimization that will save time or space and not break the
> semantics of Javascript, they are permitted to make that
> optimization. :)

Joining is more sinister than that and several messages in this thread
have approached the problem from various angles.  The worst of it is
that side effects on function objects are unpredictable, as Neil Mix
wrote earlier.  Consider:

 function f() {
   function g() {}
   if (!("x" in g)) g.x = 12;
   g.x += 10;
   return g.x;


Observe the inner function g.  By 13.1.1 bullet 1, the two uses of the
body of g are equated.  Therefore by 13.2 items 1, 13, and 14, the two
uses of g creates two objects that are joined: they have different
internal properties, but by 13.2 act as "one object" -- side effects
on one are visible on the other.

Therefore the first call to f() will return 22 but the second call may
return 22 or 32 -- either is "right".  This does not quite seem like a

What the joining spec actually means in practical terms is that "two
internal function definitions should not be used as mutable values
unless you're really careful."


Normally an implementation would care about avoiding creating closures
for nested functions that are only used as functions (ie they are only
ever called, never used as values).  There are well-known techniques
for that that that do not require joining.

We haven't discussed this in the working group.  My opinion:
Implementations that perform the optimization will probably want to
continue performing it for backwards compatibility, so the behavior
may need to be brought forward for that reason.  But only if there are
important implementations that do perform it; I haven't tested and I
haven't asked.  I'm guessing the language is in there because some
implementation did perform it, at the time the previous spec was

Input from members of the ES3 committee would be helpful at this
point.  The text does not appear in ES1 or ES2.


More information about the Es4-discuss mailing list