At 09:58 PM 9/3/2001 -0400, Ken Fox wrote:
>"Bryan C. Warnock" wrote:
> > Except that Perl 6 will have the ability to inject lexical variables in its
> > scope, and in any dynamic parent's scope. (It isn't clear whether that is
> > write-only access or not - which it probably should be for lexicals.)
> >
> > That, invariably, forces at least some run-time lookup by name, since the
> > lexicals aren't there at compile time for the early resolution.
>
>Please, please, please say that this is not like Tcl's upvar/uplevel
>stuff.
Okay, I won't. It is, though.
There is use for this. Right now, try writing a sub that alters the lexical
warning state of its caller. Go ahead, I'll wait. :) At the moment you have
to resort to XS code, since calling an XS sub doesn't get you new scope.
(And yes, this is useful--it was how the vmsish pragma was implemented
until the bug that allowed it to work was fixed)
>I was imagining the "injection" to happen *only* at compile time
>when a "use" statement replaced the scope management object the
>compiler talks to.
>
>I *really* don't like the idea of a called sub modifying its' parent's
>scope at run time. This fundamentally breaks the feature of understanding
>code just by reading it. When I see a lexical, I want to trust the
>definition.
Oh, it gets better. Imagine injecting a lexically scoped sub into the
caller's lexical scope. Overriding one that's already there. (Either
because it was global, or because it was lexically defined at the same or
higher level)
Needless to say, this makes the optimizer's job... interesting. On the
other hand, it does allow for some really powerful things to be done by
code at runtime.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
