Re: RFC 106 (v2) Yet another lexical variable proposal: lexical variables made default

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