NAME

 [DRAFT] Synopsis 28 - Special Variables [DRAFT]

Version

 Maintainer:     pugs committers
 Date:           2 Apr 2005
 Last Modified:  2 Apr 2005

This document attempts to document the list of special variables in Perl 6.

APPENDIX

Here is an e-mail from Larry on the subject;

 Mailing-List: contact perl6-language-help@perl.org; run by ezmlm
 Date: Sat, 26 Mar 2005 00:27:24 -0800
 From: Larry Wall <larry@wall.org>
 To: perl6-compiler@perl.org
 Cc: perl6-language@perl.org
 Subject: S28ish [was: [Pugs] A couple of string interpolation edge cases]
 
 On Sat, Mar 26, 2005 at 02:11:29PM +0800, Autrijus Tang wrote:
 : On Fri, Mar 25, 2005 at 10:03:45PM -0800, Larry Wall wrote:
 : > Hmm, well, if it got that far.  Given strict being on by default,
 : > this particular example should probably just die on the fact that $"
 : > isn't declared, since there's no $" in Perl 6.
 : 
 : Is $" okay as a variable name?  Is everything from perlvar.pod legal? :)
 
 Considering nobody's written perlvar.pod for Perl 6 yet, yeah, everything
 in that pod is legal.  :-)
 
 :     my $" = 3;
 : 
 : Pugs parses that because it only considers $! and $/ as legal
 : symbolic variable names.
 
 $! will be a legal variable name.  $/ is going away, as is $", which
 means they fail under "use strict", but they'd still autocreate
 globals under laxity as Perl 5 does.  (I know Perl 5 exempted all
 special variables from strict, but I don't see why we have to do
 that for Perl 6.  Merely having $_ in the lexical scope or $*! in the
 global scope should be sufficient declaration to get around strict.
 Though perhaps we can exempt people from having to write $*! under
 strict.  In fact, that probably goes for all predeclared $* names,
 so $IN is legal for $*IN as long as you don't have "my $IN" hiding
 it.  Another way to look at it is that * variables are basically
 autodeclared "our" implicitly in the outermost lexical scope.)
 
 Sigh, I'd better rough it all in here, even if I don't have time to
 do a good job on it.  Maybe somebody can beat this into a real S28 pod.
 
 $? and $@ are gone, merged in with $!.  (Frees up ? twigil for $?FOO
 syntax.)  $^E is merged too.  $! is an object with as much info as
 you'd like on the current exception (unthrown outside of CATCH, thrown
 inside).  Unthrown exceptions are typically interesting values of undef.
 
 $$ is now $*PID.  ($$foo is now unambuous.)
 
 $0 is gone in favor of $*PROGRAM_NAME or some such.
 
 Anything that varied with the selected output filehandle like $|
 is now a method on that filehande, and the variables don't exist.
 (The p5-to-p6 translator will probably end up depending on some
 $Perl5ish::selected_output_filehandle variable to emulate Perl 5's
 single-arg select().)  Likewise $/ and $. should be attached to
 a particular input filehandle.  (In fact, $/ is now the result of
 the last regular expression match, though we might keep the idea of
 $. around in some form or other just because it's awfully handy for
 error messages.  But the localizing $. business is yucky.  We have
 to clean that up.)
 
 All the special format variables ($%, $=, $-, $:, $~, $^, $^A, $^L)
 are gone.  (Frees up the = twigil for %= POD doc structures and
 old __DATA__ stream, the : twigil for private attributes, and the ~
 twigil for autodeclared parameters.)
 
 $`, $', and $+ don't exist any more, but you can dig that info out
 of $/'s structures.  Shortcuts into $/ include $1, $2, and such, and
 the newfangled $<foo> things.  Also, $& is changed to $0 for the whole
 matched string.  $` and $' may be $<pre> and $<post>, but you probably
 have to explicitly match <pre> and <post> to get them remembered,
 so we don't have a repeat of the Perl 5 sawampersand fiasco.  <pre>
 and <post> would automatically exclude themselves from $0.  Or you
 need some special flag to remember them, maybe.
 
 %+ and %- are gone.  $0, $1, $2,  etc. are all objects that know
 where they .start and .end.  (Mind you, those methods return magical
 positions that are Unicode level independent.)
 
 $* and $# have been deprecated half of forever and are gone.  $[
 is a fossil that I suppose could turn into an evil pragma, if we
 try to translate it at all.  (Frees up * twigil for $*FOO syntax.)
 
 $(, $), $<, and $> should all change to various $*FOO names.  $] is either
 something in $* or a trait of the Perl namespace.  Likewise $^V, if
 they aren't in fact merged.
 
 ${...} is reserved for hard refs only now.  ($::(...) must be used
 for symbolics refs.)  ${^foo} should just change to $*foo or $*_foo
 or some such.
 
 $; is gone because the multidim hash hack is gone.  $" is gone,
 replaced by @foo.join(":") or some such.  Likewise for $, in print
 statements.
 
 We never did find a use for $}, thank goodness.
 
 And we still are keeping $_ around, though it's lexically scoped.
 
 Let's see, what other damage can we do to perlvar.  $a and $b are
 no longer special.  No bareword filehandles.  $*IN, $*OUT, $*ERR.
 Args come in @*ARGS rather than @ARGV.  (Environment still in %ENV,
 will wonders never cease.)  I don't know whether @INC and %INC will
 make as much sense when we're looking installed modules in a database,
 though I suppose you still have to let the user add places to look.
 
 %SIG is now %*SIG.  The __DIE__ and __WARN__ hooks should be brought
 out as separate &*ON_DIE and &*ON_WARN variables--they really
 have nothing to do with signals.  I suppose we could even do away
 with %SIG and replace it with &*ON_SIGINT and such, though then we'd
 lose a bit of signal introspection which would have to be provided
 some other way.  Oh, and we probably ought to split out &?ON_PARSEERROR
 from $*ON_DIE to get rid of the $^S fiasco of Perl 5.
 
 $^C, $^D, $^F, $^I, $^M, $^O, $^P, $^S, $^T, $^V, $^X are all renamed
 to something $*FOOish, at least the ones that aren't going away entirely.
 
 $^W is is too blunt an instrument even in Perl 5, so it's probably gone.
 
 I'm not quite sure what to do with $^N or $^R yet.  Most likely they
 end up as something $<foo>ish, if they stay.
 
 You weren't ever supposed to know about $^H and %^H.  Or %{^FNORD}...
 
 Other things might show up as global variables in support of
 command-line options, like $*ARGVOUT or @*F.  Some of the special
 variables we've blissfull relegated to the trash heap might
 creep back in as global variables that just happen to know about
 $*Perl5ish::current_selected_filehandle and such, but we should
 probably try to keep them as lvalue subs in &Perl5ish::ors() and such.
 
 Anyway, it's all negotiable, except for the parts that aren't.
 
 Larry