Generator issue: exceptions while initializing arguments

Jason Orendorff jason.orendorff at
Fri Sep 14 04:54:23 PDT 2012

On Thu, Sep 13, 2012 at 8:23 PM, Kevin Smith <khs4473 at> wrote:
> No amount of argument is going to convince a user that defaults should *not*
> be executed at the location of the call.  That's just not how it reads.  No?

I kind of agree, but at this point we could do with a little less
argument and a little more in the way of concrete proposals.

So here is a concrete proposal. Please improve on it; it’s an honest
attempt, not a straw man in the rhetorical sense...

I think Allen is proposing a scheme where in code like

    function f(a1=EXPR1, a2=EXPR2, a3=EXPR3) { ... }

first EXPR1 is evaluated in a scope including only a1,
then EXPR2 is evaluated in a scope that contains a1 and a2,
then EXPR3 is evaluated in a scope that contains a1, a2, and a3,
then a new environment is created for the function body, its vars and
local functions.

If EXPR1 contains a closure that uses the name a2, that means the
global a2, not the argument a2. Even if it gets called after a2 is

In the spec language this would have to be modeled with four nested
environments; a single mutable environment wouldn't work. In
SpiderMonkey, if any of the EXPRs contained a closure that uses with
or direct eval, we would have to actually reify one of the nested
environments. Ugly but doable; any other implementors want to comment?

There would have to be some specification hackery to make this work
just like ES3 in cases where f also contains a var or function with
the same name as an argument. But Allen can do it. :)

I don’t have a strong preference. It seems to be is a classic Right
Thing vs. Worse Is Better situation. The advantage of the Worse Is
Better approach is that you can correctly and completely explain
what’s going on in one sentence: “It’s just like an if statement at
the top of the function body.”  It may not be reasonable, but ordinary
developers can reason about it. When it comes to corner cases, which
is more important?


More information about the es-discuss mailing list