develooper Front page | perl.perl6.language | Postings from July 2005

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

Thread Previous | Thread Next
Matthew Hodgson
July 20, 2005 10:59
Re: Referring to package variables in the default namespace in p6
Message ID:
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?


% 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?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About