John Porter wrote:
> > 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".
>

Take PHP and Python, for example.


> >     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.
>

Yeah. Beginners. I was one too. And I remember always falling on these...
But that's OK, since we probably don't want any new Perl programmers...




> > 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.
>

Tell me one. I couldn't find it.



> > 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;
>           }
>         }
>       }
>     }
>   }
>

Wrong! Read again:

> > 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.

***(not anonymous blocks, only subs)*** Got it?

The only change would be cutting the `my $x;' line, since all others are in
the same sub. (As you see, `my' introduces a bit more than typing two
characters).
:   # under use scope;
:   sub {
:     {
:       $x = 1;
:       {
:         $x = 2;
:         {
:           $x = 3;
:           {
:             $x = 4;
:           }
:         }
:       }
:     }
:   }

Or, the smart way:
:   sub { $x = 4; }

Or even:
:   sub { 4 }





> > 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.

print $x, $y, $z;



> > 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.
>

Sufficient? Yes.
The best way? Maybe, maybe not.
The only way? (So long,) Yes.

I think TSBMTOWTDI.



> > 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.

Hey! You are changing the meaning of what I said!!! I didn't write that!
: I also see no action at a distance here, since the only way to change the
: way a sub sees a variable is inside the sub the variable is being used.
: That's where I think the discussion about RFC 64 was problematic. It was
: assuming `our' *outside* the block would affect variables inside the
block.
: And that's AAAD for sure!

I never said `our' should affect the variables inside the block! I said this
was the *main* problem in the discussion of RFC 64! Having `our' (or
anything) outside the scope change the scope of things is a very bad idea.
It's clear it ends with all the purpose of it.



>
> I have to disagree with you.
>

Read it again, and see if it has problems or not. Note again, I'm not asking
you to use it, or even like it. I'm only asking if it has the ``far more
serious problems than it purports to solve'' you said it has.

- Branden

Reply via email to