Branden wrote:
>
> Well, I checked the archives, and I found that the discussion begun in
> http:[EMAIL PROTECTED]/msg01441.html
That thread was rather tame; even so, I believe the end result,
if one can be deduced, is that the proposal is not a good one.
There was more heated discussion in the thread rooted at
http://www.mail-archive.com/perl6-language@perl.org/msg01089.html
the discussion of RFC 16.
> Well, first let me say why I think a way (pragma) to do lexical-scope by
> default (for one file/block/scope) would be good. Most (modern) languages do
> it
This is false. Even languages in which lexical variables are the
norm still require a variable declaration; it's not a "default".
> And `my' really doesn't DWIM.
Only if WYM isn't what 'my' does. :-)
> my $a, $b, $c; # only $a is lexically scoped
RTFM.
> my ($a) = <FHANDLE>; # after deducing (by the above) . . .
> # when I wanted only the first line.
Silly beginner gotchas. It's not an inconsistency of the
language by any means.
> if ($x) {
> my $y = 1;
> } else {
> my $y = 2;
> }
> return $y; # wrong,
Just as in any language with lexical variables:
if ( x ) {
int y = 1;
} else {
int y = 2;
}
return( y ); /* wrong */
> These are the problems I see with `my', not to mention the problems that
> arise by NOT having `my' (these are quite well described in RFC 64).
Except they're not really problems, volumes of discussion
not withstanding.
> My proposal is: As most code written SHOULD have (almost) all its variables
> lexically scoped, in presence of a pragma (like `use scope'), all variables
> would be implicitly defined as lexically scoped to the named sub (not
> anonymous blocks, only subs) they're in.
This introduces far more serious problems than it purports to solve.
> To access variables outside of this
> scope, keywords would be used to statically define that a variable actually
> refers to a global variable or a variable of another scope.
I see. Instead of
sub {
my $x;
{
$x = 1;
{
$x = 2;
{
$x = 3;
{
$x = 4;
}
}
}
}
}
You'd have to write
sub {
$x = undef; # to establish it at this scope
{
outer $x = 1;
{
outer 2 $x = 2;
{
outer 3 $x = 3;
{
outer 4 $x = 4;
}
}
}
}
}
Yeah, that's much better. :-P
> I propose the introduction of two new keywords
As I said before: ain't happenin'.
> > Ugh - upvar? No thanks.
> >
>
> Actually, what I'm proposing is quite very different than `upvar'. `upvar'
> is a dynamic thing, it accesses a variable in the scope of the caller.
> `outer' is a lexical thing, it tells the compiler that that variable name is
> accessing the same variable that the definer was accessing.
You are so confused. As you say, upvar deals with scope. That's
lexical. It is *not* dynamic, which deals with namespaces.
(The documenation of upvar may talk about "global variables",
but that's just referring to the outermost lexical scope.)
So, yes, indeed, you are proposing a sort of upvar for perl. Blech.
Note that discussion of upvar also occurs under the discussion
of RFC 143.
> Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in contrast
> to `outer($x), $y, $z'.
Great. You want to break this one very consistent aspect of perl.
> I predict that you're going to say that this isn't saving typing,
No, I'm going to say that it introduces far more serious problems
than it purports to solve.
Furthermore, it adds more ways -- unnecessary ways at that -- to
do things, and more confusion for our already befuddled newbies.
> writing modules that essentially need to use lexically scoped variables to
> guarantee they won't harm scripts that use those modules, I think it's a
> win.
use strict 'vars' + my is already more than sufficient to this need.
> I also see no action at a distance here, since the only way to change the
> ...
> assuming `our' *outside* the block would affect variables inside the block.
I have to disagree with you.
--
John Porter
You can't keep Perl6 Perl5.
