I know it's unfair to comment on a frozen RFC, but I think it's
important to note a few things:
On Wed, Sep 27, 2000 at 05:22:30AM -0000, Perl6 RFC Librarian wrote:
> Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
> Status: Frozen
[snip]
> Dubbed the "conservative" approach by Mark-Jason Dominus, this option
> requires that the programmer disambiguate the situation by declaring
> the variable with C<my>. Perl would produce a warning in this case to
> the effect that, "A variable used within a block was used after that
> block, but never declared or used before it. The enclosing scope
> cannot see the same variable that exists within the enclosed block."
>
> Alternatively, if this RFC is adopted, but nothing is done to alert
> new Perl6 programmers about these possibly ambiguous cases, the
> programmer would receive a "Use of undefined value" warning which
> might suffice.
This approach to the problem is problematic to me. I, as most, C<use
strict> in any code of reasonable length. But I'm also very used to
doing something like:
[~] $ perl -wle'while(<>) { ++$foo && last if /bar/ } if ($foo) {
print "used last" }'
With the "conservative" approach, this will not DWIM. I'll get some kind
of warning about it, but having to predeclare $foo will not make me
happy.
> In the "liberal" approach, perl can do what amounts to "inferring
> declarations." To actually refer to it this way would be a
> contradiction in terms, since a declaration is explicit, not inferred.
>
> To implement the liberal approach, perl would detect all of the
> undeclared variables used within a scope when it compiles that scope.
> These variables would become available for use from the minute that
> scope is entered. Thus, in the example above, $color is detected as
> being a part of the enclosing scope before the interpreter ever enters
> the if statement, and $color therefore refers to the same scalar in
> both places.
>
> It was observed that this approach could also be implemented by
> inferring a variable to be declared at the top-level, the largest
> enclosing scope. It does not appear that there would be any
> language-visible differences in this implementation, although it would
> certainly be different to the implementors.
Erm, but this approach _really_ worries me. Doing things this way is
taking away the whole point of lexically scoped variables!
{
$foo = 0;
sub should_be_closure { $foo++ }
}
...
print "The value of foo is ", ++$foo, "\n";
Eh? We can modify the value of that variable way down here at the bottom
of the file? That's basically useless.
Obviously if you want that closure, you declare C<my $foo> in the scope
that's wanted, but I'm not seeing what this approach is buying us from
the current state of affairs.
It's possible that I'm missing something, though, and I do apologize for
not saying this earlier. After initial discussion died down on -strict,
I neglected to ever go back and say anything.
-dlc
