> > If lexical variables are the default, then 'strict vars' will be
> > totally unnecessary because it will be impossible to forget the 'my'.
>
> Actually, this is what I suggested as well, but was promptly shot down
> by Nat and others. The more I think about it, I think I understand why
> you *need* the "my". J. David pointed out that lexical scoping has a
> "non-Perl" definition:
>
> with lexical scoping a variable lookup starts in the
> current block and proceeds outwards according to
> the scope in which the block was declared
That's what 'my' variables presently mean in Perl as well. So there
is no change and no inconsistency.
> But the C one works fine. Why? Because myint's been lexically declared!
Sure. But you omitted the same lexical declaration in the Perl code.
The C example has
int myint;
at the outer scope. If you added
my $myint;
at the same place in the Perl code, it would do the same thing.
I can see a couple of ways to make this work.
The straightforward solution is to say that in this example the
declaration is required in Perl 6 if you want it to do the right
thing. The declaration is already required in Perl 5 if you are using
strict.
Now what if you leave out the declaration? Then Perl can generate a
warning about the $myint in the inner scope shadowing the $myint in
the outer scope. This is what C does. I think that this has proven
to be a successful solution for C. It might work well for Perl also.
You said it would necessarily be strange and obfuscated, and I don't
think this situation would be either strange or obfuscated. In some
cases you need to put in the declaration to get what you want; if you
leave it out, you get a warning. The declaration has the exact same
meaning that it had in Perl 5.
If you want something a little stranger though, here is another idea:
The compiler could see that you used the same variable name in the
inner and in the outer block, and infer the `my' declaration at the
top of the outer block, just as if you had put it there yourself.
This doesn't seem difficult to implement, but I don't know if it is a
good idea, because I haven't thought it all the way through, and I
can't think of any prior art. But it might be worth looking into.
I think this is what you're talking about here:
> Granted, we could also try to do some really fancy stuff with
> dynamically determining the scope, making a "best guess" as where it
> should end up.
I think that the guessing rules could be made simple, but as I said, I
don't know for sure that it would work.
But now Tom says something about how Python does this:
> Python isn't truly block-scoped, but just global-package-function
> scoped, a variable without the global keyword belongs to whichever
> of those (package global or function local) it appears in. However,
> it's highly dodgy, because if used lvaluably, it is implicitly
> package
> global, but used rvaluably, it is implicitly function local. This
> is crazy.
I agree. It *is* crazy. But just because Python got it wrong doesn't
mean we can't get it right. Python gets all sorts of things wrong.
That doesn't mean that the ideas are worthless, just that Python is
broken.
I used to think that indentation-sensitive block structure was a bad
idea, because Python was the only example I had ever seen. But then I
saw how Haskell does it, and I realized that it wasn't a bad idea;
it's just that Python screwed it up.
So I don't think that Python's stupidity is a good argument against
this, unless the stupidity is really unavoidable.
