Front page | perl.perl6.language |
Postings from July 2005
Re: Referring to package variables in the default namespace in p6
Thread Previous
|
Thread Next
From:
Thomas.Sandlass
Date:
July 20, 2005 10:05
Subject:
Re: Referring to package variables in the default namespace in p6
Message ID:
42DE8437.5060008@orthogon.com
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ß)
Thread Previous
|
Thread Next