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

[TSa (Thomas Sandlaß)]

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