Re: Referring to package variables in the default namespace in p6

[Matthew Hodgson]

On Tue, 19 Jul 2005, Larry Wall wrote:

On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote:
:
: So the question is: what is the correct syntax for referring to package
: variables in the default namespace?

The * looks like a twigil but it isn't really.  It's short for "*::",
where the * is a wildcard package name, so in theory we could have
$=*foo, meaning the $=foo in the *:: package.  (But most of the
twigils imply a scope that is immiscible with package scope.)

So, if I understand this correctly, the conclusion for referring to the 
default program namespace is $*Main::foo - which is shorthand for 
$*::Main::foo, which pulls the variable $foo out of the globally-rooted 
namespace called Main.  I'll plonk some tests into pugs to try to steer 
towards that...

In terms of resolving non-fully-qualified namespaces, presumably 
$Main::foo would work most of the time, assuming that you weren't 
currently within any package/module/class namespace scopes called Main - 
as S02 says 'the "*" may generally be omitted if there is no inner 
declaration hiding the global name.'?

: Also, what is the correct syntax for referring to package variables in
: your 'current' namespace?  $::foo?  $?PACKAGENAME::foo?
: $::($?PACKAGENAME)::foo?  %PACKAGENAME::<foo>?

That's currently:

   $OUR::foo

right... I guess that goes with $MY:: and $OUTER:: in S06 and their 
respective hash access methods.

I'm very surprised that package variables end up in OUR::, however - 
because surely they're not necessarily lexically scoped - and the whole 
point of 'our' was lexical global scoping, right? :/

is being able to:

% perl6 -e '{ $*Main::foo = "foo"; } say $OUR::<$foo>'

really a feature?  Or is OUR:: actually intended to include non-lexically 
scoped package variables too as a special case?

I'm not sure whether $::foo
is usefully distinct from $foo these days.  It almost seems to imply
that ::foo is in type space and we have to dereference it somehow.
There's a sense in which :: only implies type space after a name.
We somehow seem to have the situation where :: is simultaneously
trying to be a leading sigil, a trailing sigil, and a separator.

I've tried to wrap my head around all these behaviours of :: and summarize 
them here for future readers: inevitable corrections more than welcome ;)

::Foo          # leading sigil: disambiguates Foo as being in type space
$Foo::bar      # trailing sigil: indicates preceding term is in type space 
$Foo::Baz::bar # separator: type space hierarchy separator

::($foo)       # special case leading form which behaves more like the
               # trailing sigil & separator form for building up type
               # terms from expressions, as ($foo):: would be ambiguous.

I assume that I am correctly following your lead in referring to 
package/module/class namespaces as 'type space' here...

As regards $::foo, making a special case for it being a synonym for 
$*Main::foo be yet another complication entirely without precedent in the 
current behaviour.  But then again, using $::x in the past as a quick way 
to disambiguate between lexical & package variables in simple package-less 
scripts was quite handy...

thanks hugely for the quick feedback :)

M.