On Mon, Jan 16, 2006 at 02:38:14PM +0800, Audrey Tang wrote:
: -BEGIN PGP SIGNED MESSAGE-
: Hash: SHA1
:
: I'm almost sure this had been covered before, but I failed to find a
: reference in either the archives or in synopses, so here goes again:
:
: sub f ($x) {
: sub g ($y) { $x + $y }; g($x);
: }
: f(10); # 20?
:
: Currently in Pugs, g is built at BEGIN time when f had not finished
: building up its lexical environment, and as such fails to see the
: runtime $x. The desugared form is:
:
: our g;
: BEGIN { g := sub ($y) { $x + $y } }
:
: However, the following form does work in the Parrot, JavaScript and
: Haskell runcore:
:
: sub f ($x) {
: my sub g ($y) { $x + $y }; g($x);
: }
:
: the reason it works is that g's body is replaced every time upon f's
: entry. This is probably the expected behaviour.
Yup.
: What would happen for the our sub g form, where it becomes possible to
: call g directly without entering f? This shows Pugs's current behaviour:
:
: sub f ($x) {
: our sub g ($y) { $x + $y }; g($x);
: }
: f(10); # 20 for sure
: our g; # gets visibility to g
: g(100); # 110 this time?
:
: So my questions are:
:
: * Is the treatment above sane?
I think so, under the theory that g is just a persistent form of the
closure that happens to be cached in the symbol table rather than
in some $ref variable. Though I can see temp our g being put
to interesting uses if g is getting arbitrarily rebound at various
points whenever f is called...
: * Does it make sense to change the undecorated sub g's behaviour to
: match our sub g?
Yes, at least for any block that really is capturing a closure.
Perhaps we need to distinguish those from accidentally nested
top-level functions. But undecorated sub is more-or-less defined
to be our sub anyway, just as with package, module, and class
these days. The only difference is that our explicitly introduces
a lexically scoped alias, while the undecorated form presumably doesn't.
Though we could break that too, I suppose.
: * If we insert a call to g() above without calling f() first, should it
: assume an uninitialized $x, or throw an exception (Pugs currently does
: the latter)?
An exception is fine, modulo what I said about accidental nesting.
When do you detect the condition? If the inner function can't
reference $x, does it still fail? On the other hand, we can get into
eval issues where it might or might not reference $x. I'm okay
with requiring lexical scopes to have some existing relationship
with dynamic scopes, especially when we know some initialization is
required.
Larry
