On Sep 25, 2004, at 10:27 PM, Larry Wall wrote:
On Sat, Sep 25, 2004 at 10:01:42PM -0700, Larry Wall wrote: : We've also said that MY is a pseudopackage referring to the current : lexical scope so that you can hand off your lexical scope to someone : else to read (but not modify, unless you are currently compiling : yourself). However, random subroutines are not allowed access : to your lexical scope unless you specifically give it to them, : with the exception of $_ (as in 1 above). Otherwise, what's the : point of lexical scoping?
Note that this definition of MY as a *view* of the current lexical scope from a particular spot is exactly what we already supply to an C<eval>, so we're not really asking for anything that isn't already needed implicitly. MY is just the general way to invoke the pessimization you would have to do for an C<eval> anyway.
A mildly interesting thought would be for C<eval> to take additional parameters to make explicit what's visible to the eval'd code--essentially making the running of the code like a subroutine call. So the traditional C<eval> would turn into something like "eval $str, MY", but you could also have "eval $str, $x, $y", or just "eval $str", which would execute in an "empty" lexical scope. That would allow additional optimizations at compile-time (and make MY the sole transporter of lexical scope), since not every C<eval> would need what MY provides, but even more importantly, it would allow the programmer to protect himself against accidentally referencing a lexical he didn't intend, just because the code in his string coincidentally used the same variable name. More optimization opportunities, and more explicit semantics.
But that's now a language issues, so I'm cc-ing this over to there.
JEff
