In both cases the variable is always kept in package main. And both syntaxes will not be supported in Perl 6.

Except that starting a variable name with a ' is just a hack for starting it with a ::, which doesn't stop me from then appending a different namespace. The ^ hack is totally separate.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

I just said what would work, not why it does.

You might also have noted that I did not say why each solution was going to not be supported in 6.0. I have to leave people some incentive to re-read the documentation! :-)

As tilly pointed out, variables such as ${^Foo} and @{^_I_Like_Pie} are not only global, but also ignore package declarations, and are the same in every package. ${^Foo} means $main::^Foo, regardless of what package declaration is in scope. But note also that they are all reserved for future extensions, except the ones beginning with ^_. So the official answer to your question is either

Write the empty package qualifier explicitly, as $::foo or $'foo

Use a variable like ${^_foo}

As the man page mentions, there are a few other variable names that are interpreted independent of the current package: %ENV, STDIN, @ARGV, and so on. There is absolutely no way to create new special variables of this type without modifying the Perl core. (See the code in the vicinity of line 588 of gv.c to see why.) But if you really want to, you can take over the unused variables with the same names, such as $ENV, @STDIN, and %ARGV, and use those; they get the same special treatment even though Perl doesn't use them for anything. Similarly, punctuational variables such as @* and %: ignore the current package declaration and are always taken to be in package main.

Hope this all helps.

--
Mark Dominus
Perl Paraphernalia

BEGIN {
  %main::_shared_vars = (
    the_very_global => \$the_very_global
  );
}
INIT {
  package main;
  sub _iterate_packages_loop {
    my($stash,$name,$callback) = @_;
    $callback->($stash,$name);
    foreach (keys %{$stash}) {
      if (/::\z/ and $_ ne "main::") {
      _iterate_packages_loop($stash->{$_},$name.$_,$callback);
      }
    }
  };
  sub _iterate_packages {
    _iterate_packages_loop(\%::,"main::",shift);
  }
  _iterate_packages(sub { 
    $_[1] eq "main::" and return;
    while (my($k,$v) = each %::_shared_vars) {
      $_[0]->{$k} = $v;
    }
  });
}

$the_very_global = "GLOBAL!\n";

print $the_very_global;

package bar;

print $the_very_global;

package bar::foo;

print $the_very_global;
[download]

Fixing this technique to work with use strict can be done by overriding the strict pragma. One can even override it such that strict works as a source-filter that detects package usage and imports the variables appropriately before the code using them is compiled, so most of the advantage of using strict is not lost. I also use caller so if one does package Foo; use strict; it will still work. use strict; package Foo; (on one line) is not likely to work, however.

BEGIN {
  %main::_shared_vars = (
    the_very_global => \$the_very_global
  );
}
BEGIN {
  use Filter::Util::Call;
  use strict;
  my $_strict_import = \&strict::import;
  package strict;

  sub _add_to_stash {
    my $name = shift;
    no strict 'refs';
    while (my($k,$v) = each %::_shared_vars) {
      # importing this way makes the variable
      # be considered "declared" for the purposes
      # of strict.
      *{$name."::$k"} = $v;
    }
  };
  *strict::import = sub {
    # setup the package we are being called by
    _add_to_stash(scalar caller);
    filter_add(sub {
      my $status;

      while (($status = filter_read()) > 0) {
        _add_to_stash($1) while /package\s+([\w:]+)/g;
        last unless(/package\s*\z/);
      }
      return $status;
    });
    goto &$_strict_import;
  };
}
[download]

Note that this code doesn't do very smart parsing of package names. I think that's okay since getting false positives is not really a problem. A combination of these two strategys should work except for compile-time run code that doesn't use strict and run-time generated packages that don't use strict. Note that the strategy used with strict can be applied to any module.

There are probably other ways to do this too. The debugging mechanisms may be able to obtain the necessary information to check for package declarations in files after they are loaded and before they are compiled. Alternately, one could write a source filter that does good parsing of perl (Text::Balanced would be helpful) and find all the package declarations and recode requires, dos, evals, uses etc. into something that would also check for package statements appropriately. (The filter would presumably be setup with the main program and work it's way from there.) This would probably be much, much harder than any of the methods mentioned here, though it would be more effective.

  %% = (foo => 23);
  package xxx;
  print $%{foo};
[download]

The situation with ${^Name} variables is a little more complicated: the fact is that any variable name that starts with a punctuation character is implicitly global, but the Perl parser only recognises single punctuation characters. There's one exception to that: you can also use :: as a name, so you can use the variable $:: which is of course global. (And no, it's not a package qualifier - the variable really is called ::. The reason it's allowed is because the root symbol table hash is called %::, so the variable name tokeniser needs to let it through.) But underneath, any string of characters which begins with punctuation will force globality:

  ${'@$??!'} = "Weird!\n";
  package SomewhereElse;
  print ${'@$??!'}
[download]

  ${^Hello} = "Curious...\n";
  print ${"\bello"};
[download]

Said robin:

Something that hasn't being mentioned is that all punctuation variables are always global, even if they aren't magical.

I did say this.

The situation with ${^Name} variables is a little more complicated: the fact is that any variable name that starts with a punctuation character is implicitly global, but the Perl parser only recognises single punctuation characters.

The actual rule is that any name that starts with a character other than a letter or underscore is global. (Unless your source code is written in unicode, in which case i don't know what happens.) So in particular, $0 and $1 are global. Variables like ${^Name} don't start with punctuation either: As robin said, this one appears to start with ^, but actually it starts with the control-N character. Since control-N isn't a letter or underscore, ${^Name} is global.

There's one exception to that: you can also use :: as a name, so you can use the variable $:: which is of course global.

Not so. $:: is actually the same variable as $main::main::. (Thanks to Abigail for tracking this down.) There's a special case in gv.c that treats an empty package name as main, and it gets invoked twice here.

--
Mark Dominus
Perl Paraphernalia

The only global variables that I know of are the one's created by perl, and they tend to be magical (e.g $! yields the current value of errno when in a numerical context, and an error message in a string context).

Cheers,
-- moodster

I'm having a cold and my brain is only operating at half speed right now, so maybe I'm just confused. But I always thought that variables lived either in scalar or list context. Are there such beasts as numerical and string contexts as well?

Indeed in Perl 5 (and earlier), as opposed to Perl 6, there is no precise notion of numerical or string contexts. However those terms are sometimes loosely used to indicate "used as a number" and "used as a string respectively": in some cases, but by no means in all of them, there's an actual difference.