On Sat, Sep 25, 2004 at 11:49:26AM -0700, Jeff Clites wrote:
: >It also makes up-call lexical peeking and modification impossible.
: >This is something Larry's specified Perl 6 code will be able to do.
: >
: >That is, any routine should be able to inspect the environment of its
: >caller, and modify that environment, regardless of where the caller
: >came from.
:
: If I'm interpreting that correctly, then it may just have the
: consequence that the Perl6 compiler can perform fewer optimizations
: than others. (And if the body of a sub can reference and modify
: lexicals in its caller, then it sounds like they're not really
: *lexicals*, which is confusing....) Hmm, that also precludes part of
: what tail-call optimization usually gives you, since you can't "reuse
: the current stack frame", if the called sub is supposed to be able to
: look back at the caller's state, so you lose the potential for
: unbounded recursion. If that's all correct, Perl6 is giving up a lot
: for that "peeking" feature.
You folks are making it sound as if we want to cheat on lexicals all
over the place. That isn't exactly what we've said. As far as I know,
the only places Perl 6 has to cheat on the lexical scoping (apart
from debugging) are:
1. to be able to refer to the caller's $_ variable as $CALLER::_
so that inner closures can default their $_ to be an alias to
the outer $_ if whatever calls the closure doesn't supply
a value for it.
2. to add lexicals to a pad that is currently being compiled,
mostly so that we can export to lexical aliases.
It would be nice if 1 could be extended to refer to any lexical in
the caller's scope, but there are obvious difficulties with that.
In any event, we've only ever thought that CALLER:: could reasonably
work for variables that are known to exist in every sub, which
basically comes down to $_, and maybe $0. (And maybe pseudovariables
like $?LINE and such, but all that stuff would really have to be
accessibly somehow through caller() in any event.)
As for 2, we could actually get away without it if a "use" can return
a bit of code to be compiled and/or instantiated in the context being
compiled, as long as that bit of code can refer somehow to lexicals
being exported from the exporting module.
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?
Also, the MY pseudopackage is the *view* of the lexical scope at
the point the MY is mentioned. Different subscopes can, as you've
pointed out, have different views of the set of variable names.
There's actually no way in Perl 6 to just hand someone a pad--you
can only give them a snapshot of all the surrounding pads from the
viewpoint of a particular point in the code. At least, that's how I
have always thought of it. Any other way of doing it would be tied
terribly to the implementation of pads. A caller() function might
have to root through actual pads to provide such a view, but it
would probably be a mistake to provide a Perl interface to the raw
pad itself.
In any event, optimizations that clobber various kinds of caller()
information should at least be possible by special request, even
if not done by default. Dan and I are both speed freaks, and would
like to keep at least the *potential* for speed there. If something
doesn't seem to square with that, either we have a really good reason
for trading away the speed, or we've been misunderstood, or we've
been stupid. (Not that those three things are mutually exclusive...)
Larry
