I've been wanting to respond to these issues for the past two days,
but I've stopped short while I tried to consider everything.
This email dealt with making lexical variables default to being
available at the outermost scope (file). I'm not sure that's what
people usually mean when they think of lexical scoping. I'm also not
sure if there's a language visible difference. (There is a difference
at the implementation level, though, to be sure.)
I wrote (RFC 106):
>> =item 2
>>
>> In the "liberal" approach, perl can do what amounts to "inferring
>> declarations."
Nate Wiger wrote:
> This is the way it has to work if I'm going to agree with it. However, I
> don't think the implementation needs to be nearly as complicated as this
> RFC proposes. Consider this code:
>
> $x = 15;
> $y = $x;
> while ($y) {
> $z = $y;
> $x += $z;
> }
>
> As you state, "$z is a lexical available only in the while loop".
> However, you also state that Perl will automatically scope outwards to
> the outermost one it find, so if I add a
>
> print "z = $z\n";
>
> At the bottom, now $z is available outside as well.
Yes, it almost seems like there is no language visible difference
between having the variable exist in the outer scope (file) and having
it exist in the outermost scope in which it is referred to. Please
correct me if you are thinking of one.
> Ok, but then why bother going to the trouble of scoping it so tightly to
> begin with? If you're just going to automatically scope it to the
> outermost one, then this is equivalent to no scoping at all (do you
> see?). The only reason you'd want to scope something tightly is to:
>
> 1. Make it inaccessible to other routines
That would be the whole point of lexical variables.
>
> 2. Hide another lexical variable
Really, though, the idea in mind (especially if you're writing a
module for the rest of the world, or even just part of a big
multi-developer project) is that your variables should be lexical not
to "hide" another variable (since you usually won't know what other
variables people are using), but to avoid intruding into someone
else's namespace. Same thing, but thinking from the other direction.
It just seems safer to tie everything down to the lowest block you
can get it into.
> However, automatic scoping can't address either of these concerns. You
> have to do this explicitly with my(). As such, there's no benefit to
> liberal lexical scoping over package-wide scoping by default. As soon as
> you access a variable outside a block, that variable is rescoped
> outwards automatically.
I may be making a bad assumption here, but since a package is
usually (but not always) defined one per file, I'm assuming that in
several of these places where you said "package" we should perhaps
think "file."
> I propose the following modifications to this RFC. You'll wind up with a
> much more stable and faster implementation, I think:
>
> 1. All variables are lexically scoped at the package
> level by default, like our().
>
> 2. You can explicitly scope variables to a block with my().
If I'm correct in asserting that there are no language-level
differences, then I think we should recommend whichever is easiest to
the implementers. I'm still unclear on which of these two approaches
sounds easiest to implement, and I have zilch knowledge of the Perl5
internals folks will have in mind when they start implementing Perl6.
Like I said, I just feel that keeping everything restricted only to
the block in which it exists is least likely to have an unexpected
side-effect.
Note that with debuggers and "eval," all bets may be off. This
actually does show a difference in the language, I think. I'm not
sure how anyone would want this to go.
> 3. We introduce a new keyword, say "your()", that makes
> variables true dynamic variables.
:) Yes, I know you're pretty happy about your(). All I really have
in mind is just the same effect the vars pragma has right now. I'm
not sure if or how people will want to rename it. our() doesn't do
the exact same think, I don't think, although I've been alternately
led to believe it does and that it doesn't. (That email in the p5p
archives you referred to sure helped; thanks.)
> The #3 one might not be necessary if we eliminate dynamics altogether
> and make now() (or local or whatever) work on the lexicals correctly.
Sounds good to me. :)
J. David
