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

Matthew Hodgson wrote:
> On Tue, 19 Jul 2005, Larry Wall wrote:
>> The * looks like a twigil but it isn't really.  It's short for "*::",

Is *:: going up to the outermost Perl6 bubble or to the interpreter
that handles it? I mean where do gateways to other languages show
up: parallel to *::Perl6 like *::Python, *::Ruby or one below that?
Actually both might make sense. The pure *::Language goes for Parrot
level barebone inter language while *::Perl6::Language goes through
Perl6 wrappers/adapters.

Or would the differentiation between

   $*Foo    #  $*::Perl6::Foo

and

   $*::Foo  #  start at interpreter level

be too subtle? Hmm, it might be needed to disambiguate *foo
which could mean 'call outermost foo' or 'call innermost foo and
cast return value to list'. Well, or the prefix ops * and **
need whitespace then: * *foo; ** *foo;


>> 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.)

I still consider sigils/twigils as minimum type mark-up---or make-up :)


> 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?
The care takers of OUR:: are the package, module, class and
role meta classes while MY:: is handled by everything in braces
basically.

This at least is how I think of lexical scoping.
Correct me if I'm wrong, please!


> 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.

    Question: how are sigil and name lookup prioritized? I mean
              does a matching sigil type further outwards, and
              when a path is used from there inwards, overwrite
              a closer type mismatch? My guess is: 'sigil rules'.

    Question: does .::Foo::bar parse and does that also work
              for private data access in class scope like .:::Foo::bar
              or .::Foo:::bar? In the first case :Foo is a trusting
              private sibbling whose .bar method shall be called.
              In the second example the private method .:bar from the
              one-outwards scope Foo shall be called.


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

Hmm, if that is the name for nameespace now, so be it. But to me
it is still the plain old strictly tree-structured name space
lookup. The point is that what you---or actually the compiler---
get from there is *type* information!


> 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...

The question that nags me is where autovivified variables go to
and when. I think the compiler has the information about all lexicals
and could put them in the right place in the name space tree *before*
execution. Would that be at CHECK or INIT time?
-- 
TSa (Thomas Sandlaß)

• Referring to package variables in the default namespace in p6 by Matthew Hodgson
• Re: Referring to package variables in the default namespace in p6 by Larry Wall
• Re: Referring to package variables in the default namespace in p6 by Matthew Hodgson
• Re: Referring to package variables in the default namespace in p6 by Thomas.Sandlass
• Re: Referring to package variables in the default namespace in p6 by Matthew Hodgson
• Re: Referring to package variables in the default namespace in p6 by Thomas.Sandlass
• Re: Referring to package variables in the default namespace in p6 by Matthew Hodgson
• Re: Referring to package variables in the default namespace in p6 by Thomas.Sandlass
• Re: Referring to package variables in the default namespace in p6 by Matthew Hodgson
• Re: Referring to package variables in the default namespace in p6 by Thomas.Sandlass
• Re: Referring to package variables in the default namespace in p6 by Dave Whipp