Re: Why are subs matching /^[\W_]$/ global?

On Wed, Jun 2, 2010 at 14:18, Abigail <[email protected]> wrote:
> On Wed, Jun 02, 2010 at 02:03:26PM +0000, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Jun 2, 2010 at 13:13, Abigail <[email protected]> wrote:
>> > On Wed, Jun 02, 2010 at 12:46:44PM +0000, Ęvar Arnfjörš Bjarmason wrote:
>> >> Single-character non-alpha (plus _) subroutines are global
>> >>
>> >>     $ perl -le '** = sub {warn "Hi"}; package Foo; &*'
>> >>     Hi at -e line 1.
>> >>
>> >>     $ perl -le '*a = sub {warn "Hi"}; package Foo; &a'
>> >>     Undefined subroutine &Foo::a called at -e line 1.
>> >>
>> >> and:
>> >>
>> >>     $ perl -le '*_ = sub {warn "Hi"}; package Foo; &_'
>> >>     Hi at -e line 1.
>> >>
>> >>     $ perl -le '*__ = sub {warn "Hi"}; package Foo; &__'
>> >>     Undefined subroutine &Foo::__ called at -e line 1
>> >>
>> >> This came up when I was looking at _() in Perl as a potential Gettext
>> >> wrapper (I know about the _ filehandle).
>> >>
>> >> _ I think I can understand (presumably the _ glob is global). But why
>> >> does this apply generally to all /^[\W_]$/ subs? Is it explicitly
>> >> documented somewhere? Perhaps it's something we'd want to deprecate?
>> >>
>> >
>> >
>> > Documented. From perlvar:
>> >
>> >       Perl identifiers that begin with digits, control characters, or
>> >       punctuation characters are exempt from the effects of the "package"
>> >       declaration and are always forced to be in package "main"; they are
>> >       also exempt from "strict 'vars'" errors.  A few other names are also
>> >       exempt in these ways:
>> >
>> >               ENV             STDIN
>> >               INC             STDOUT
>> >               ARGV            STDERR
>> >               ARGVOUT         _
>> >               SIG
>> >
>> >       In particular, the new special "${^_XYZ}" variables are always taken to
>> >       be in package "main", regardless of any "package" declarations
>> >       presently in scope.
>> >
>> >
>> > Note also that perlvar claims all such names are reserved for special uses
>> > by Perl. From the same manual page:
>>
>> Thanks. I was looking in perlsub and friends.
>>
>> >       Perl variable names may also be a sequence of digits or a single
>> >       punctuation or control character.  These names are all reserved for
>> >       special uses by Perl; for example, the all-digits names are used to
>> >       hold data captured by backreferences after a regular expression match.
>> >       Perl has a special syntax for the single-control-character names: It
>> >       understands "^X" (caret "X") to mean the control-"X" character.  For
>> >       example, the notation $^W (dollar-sign caret "W") is the scalar
>> >       variable whose name is the single character control-"W".  This is
>> >       better than typing a literal control-"W" into your program.
>> >
>> >
>> > Basically, it comes down to, "if it global, you can't have it anyway".
>>
>> Right, but if it's reserved by perl, perhaps we should warn and
>> eventually prohibit uses of these constructs. As-is you can define and
>> use a sub called *, even though it's reserved.
>
>
> Why? It has worked for over a dozen years or so. So what if someone
> defines a sub &,. I don't see p5p making &, a core function anytime soon.
>
> It might have been something to prohibit when 5.000 was developed, but
> I don't see any benefits to warn, and later prohibit this now.

To reduce the mismatch between what the POD claims, and what the
implementation actually does. That there isn't even a warning when you
use something that's "reserved for special uses by Perl" seems like an
implementation omission.

It'd also be friendly if this:

    package Meh;
    use warnings 'danger_will_robinson';
    sub x {}
    sub _ {}

Noted to the naïve user that Perl's magically using odd scope
semantics for "_" that don't apply to "x". That's the reason I ran
into this.