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