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

[Matthew Hodgson]

On Wed, 20 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:

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? :/

Sorry, what is 'lexical global scoping' e.g. compared to
non-global lexical scoping? Is it not so, that conceptually
a program that is loaded from several files can be seen as
a complete nesting of all used packages, modules, classes
etc. where the file scopes are replaced by pairs of braces?

Sure - a nesting of namespaces as opposed to lexical pads.

The care takers of OUR:: are the package, module, class and
role meta classes while MY:: is handled by everything in braces
basically.

Well, when I saw the pseudo-namespace OUR::, my first thoughts were that 
its contents would be the current our()d variables which we can access in 
a non-qualified manner in our current lexical pad.  Not that it was 
actually all the package variables in our current namespace, be they 
currently lexically accessible or not.  Surely this pseudo-namespace 
should be called PACKAGENAME:: or something rather than OUR:: in order to 
avoid this confusion?

Whilst:

% perl -we 'use strict; { our $foo = "foo"; } warn $::foo'

makes sense in perl 5, I still maintain that:

% perl6 -we '{ our $foo = "foo"; } warn $OUR::foo'

is kinda confusing ;)

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.

Isn't it easier to say that :: is a unary/binary, right associative
pseudo operator with the following properties:

1) whitespace around :: is not allowed
whitespace to the left stops outwards scanning
this allows ?? ::

2) its rhs is the leaf name you want to refer to

3) the lhs is the namespace path to that leaf

4) a * wildcard starts lookup from the root
(for details of *Foo versus *::Foo see above)

5) parentheses cause symbolic runtime lookup, otherwise
the lookup is at compile time and needs pre-declared
names because there are no barewords

6) a sigil determines the type you want to refer to:
no sigil means autoderefed---that is called---Code
whitespace means a type (if more than one leaf
matches because the name is overloaded the least
upper bound (lub = any type junction) supertype is
returned.

These rules are all fair enough - but they are then ambiguous for $::Foo. 
Is that the leaf name variable Foo in your current (innermost) namespace? 
Or is it an attempt to dereference the disambiguated type Foo?  Or is it 
like perl5, shorthand for $*Main::Foo?

Is there any reason why $::Foo could not do both, and not start by 
searching your current namespace for a variable called $Foo... and then 
start searching your current namespace hierarchy for a type called Foo and 
try to dereference it (whatever that does)?

Presumably it should behave in precisely the same way that $::('Foo') does 
for sanity - does that search the current namespace for just types or 
variables or both?

M.