Here's an attempt at a crucial experiment:
js> var g = 'now'
js> function f(a = g) { yield a; }
js> var it = f()
js> g = 'later'
"later"
js> it.next()
"later"
So I'm wrong, SpiderMonkey inserts the impliciti |yield;| before
parameter defaulting. Rats.
It may not matter, but I still think early beats late. That Python binds
in the definition context may still be relevant, even though Python
evaluates parameter default values at function definition evaluation
time (way early), insofar as translating the above to Python:
Python 2.6.6 (r266:84292, May 28 2011, 19:08:00)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> g = 'now'
>>> def f(a = g):
... yield a
...
>>> it = f()
>>> g = 'later'
>>> it.next()
'now'
does indeed result in 'now'.
/be
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Sep 8, 2012, at 3:20 PM, Brendan Eich wrote:
SpiderMonkey (Firefox 15 and newer has default parameters):
js> function f(a = g) { function g(){}; return a; }
js> f()
function g(){}
So function g is hoisted and a defaults to it, as expected.
While I agree that the above is reasonable behavior. It wasn't the
consensus that was reach earlier this year at the Jan. (or may
March??) meeting. What we agreed upon is that default value
expressions in parameter lists have visibility to the left and upward
in scope but do not have visibility of anything declared within the
curlies that surround the body. So, in the above example, g should
be a reference error when evaluated as a default value initializer.
As the NOTE in step 9 of 10-5-3 says:
NOTE Binding Initialisation for formals is performed prior to
instantiating any non-parameter declarations in order to ensure that
any such local declarations are not visible to any parameter
Initialisation code that may be evaluated.
You're right, I had forgotten that.
Is it well-motivated other than in the naive left-to-right sense,
which function hoisting already violates? Perhaps, because parameters
to the right are not yet bound.
If so, then I can live with it, and g in the f(a = g) bit above would
use an outer g, if any (or throw on undefined g).
But this still does not mean the implicit |yield;| at entry to
generator function should be other than observably "after" parameter
defaulting, so that we get the throw at loc 1. Right?
IOW, this is a tangent, good to nail down (sorry for prying it up),
but not a crucial experiment for generator default parameter semantics.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
