Re: Referring to package variables in the default namespace in p6
Matthew Hodgson wrote:
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?
It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost names to
their body:
sub foo ( $param )
{
say $::param; # prints argument bound to $param
say $param; # same
say $OUTER::param; # prints value of result of a lookup
# that starts outside of sub foo
# but
my ::param $x = ::param.new; # look for param type info
# The above compiles preliminarily but eventually needs
# a type param. If the only name that is in scope is the
# formal param then I presume a late compile error occurs.
# Well, or the runtime *value* of $param is taken as the
# type which essentially renders $x a constant.
# and
my param $y = param.new; # works only if param pre-declared.
# Also
say param(); # requires a code type to be in scope
say param(); # same with late binding
say .param(); # late binding with method sigil
}
Interesting question is how the last two lines above behave depending
on whether param.does(Sub) or param.does(Method) and what light
that sheds on the $?SELF.method problem :)
Or is it an attempt to dereference the disambiguated type Foo?
What is the use of reference to a type? The compiler, dispatcher
and class and object composer need type information to do their
job, of course. And they might handle this information through
refererences. But when this happens the source is already digested.
In other words you just can't use a sigiled expression where a type
is expected: my $::Foo $x; is just a syntax error. This is why I regard
the sigils as type mark-up. That means writing $Foo or $::Foo just
tells the compiler that you want to handle the item Foo.
Or is it like perl5, shorthand for $*Main::Foo?
This is clearly specified as not beeing the case.
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)?
This is my position if I read the double negation correctly.
Sorry if that wasn't clear initially. But I hope the above rants
clarify what I mean.
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?
Not for sanity. $::Foo is just syntactic sugar for $::('Foo') because
'Foo' is a compile time constant. But $::( some_calculated_name ) might
not in general be evaluateable at compile time and thus forces the
compiler to generate symbolic lookup code which
1) calls some_calculated_value
2) starts lookup with the stringified return value
Note that because of the $ sigil it looks for something that does the
Scalar/Item role! We can consider the sigils as lookup filters.
Regards,
--
TSa (Thomas Sandlaß)
Re: Referring to package variables in the default namespace in p6
On Thu, 21 Jul 2005, TSa (Thomas Sandlaß) wrote:
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo=Foo; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then $::Foo should end up referring to the same variable.
Let me restate that in my own words. You mean that a symbolic runtime
lookup $::($Foo) with the value of $Foo at that time shall be cached
in the immediatly surrounding namespace and that cached ref is then
accessable through the syntax $::Foo?
Hm, I seem to be making a bit of a pigs ear of explaining myself here, but
thank you for bearing with me. What I was trying to confirm was that
if you create a variable in your immediately surrounding namespace:
$*Main::foo = 'bar'; # (assuming you are in the default namespace)
and a variable containing the string 'foo':
my $varname = 'foo';
then the principle of least surprise suggests to me that the result of
evaluating $::($varname) should be identical to that of evaluating $::foo.
I wasn't getting hung up on whether $::($varname) should somehow be cached
to avoid a dynamic lookup based on the current value of $varname every
time. And I assume that if $*Main::foo hadn't been created, assigning to
$::($varname) would create it as expected (again, without any caching of
$varname).
My confusion initially stemmed from chat on #perl6 about $::Foo and
$::('Foo') being Very Different Things - and the fact that there was ever
any confusion over whether $::foo was your 'closest' $foo variable or
something else.
BTW, I wonder if $::() means $::($_) :)
hehe; that would almost be nice... :)
Otherwise the two $::... forms would be horribly confusingly different
Sorry, they are the same thing: namespace lookup. But without ::() the
compiler does it at compile time for bareword resolving. Without a sigil
in front the result can be used where a type is expected:
for (blahh, fasel, blubber) - $name
{
($name).new;
}
We can consider the equivalence of $foo and $::foo as TIMTOWTWI.
I dought that assigning two different meanings just because their
are two syntactical forms is a good idea.
Fantastic - all my fears are allayed, then. $::foo is $::('foo') is $foo
(assuming it hasn't been our'd or my'd), and all is well in the world.
[lest] I (and other future legions of newbies) would despair. :)
You consider yourself a 'legion of newbies' ;)
Well, earlier I may have been legion, but I think i've regained my karmic
balance a bit now... ;)
cheers;
M.
Re: Referring to package variables in the default namespace in p6
HaloO Matthew,
you wrote:
I wasn't getting hung up on whether $::($varname) should somehow be
cached to avoid a dynamic lookup based on the current value of $varname
every time. And I assume that if $*Main::foo hadn't been created,
assigning to $::($varname) would create it as expected (again, without
any caching of $varname).
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's your program die.
Unfortunately I'm unsure how the runtime interface to
making dynamic namespace entries looks like. Note that
the operator ::= acts at compile time, too.
My guess is that the compiler collects all potential data
items and arranges for auto-vivification and/or autoloading
and even on-the-fly instance composition and such like things.
But for symbolics this is your task.
My confusion initially stemmed from chat on #perl6 about $::Foo and
$::('Foo') being Very Different Things - and the fact that there was
ever any confusion over whether $::foo was your 'closest' $foo variable
or something else.
So to conclude, for reading they amount to the same result but through
different paths. But since the symbolic lookup might result in undef
the behaviour for writing is indeed a Very Different Thing.
@Larry, please correct if I gave wrong advice.
--
TSa (Thomas Sandlaß)
Re: Referring to package variables in the default namespace in p6
TSa (Thomas Sandlaß) wrote:
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's your program die.
When something knows that it is being evaluated in lvalue context, it
should probably return something like undef but autovifify:{...}. The
assignment operator could then check for the autovivify property when
its LHS is undefined.
Re: Referring to package variables in the default namespace in p6
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?
Whilst:
% 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?
M.
Referring to package variables in the default namespace in p6
Hi all, I've spent some of the afternoon wading through A12 and S10 trying to thoroughly understand scope in perl 6, in light of the death of use vars and the addition of class (as well as package module) namespaces. In the process I came up against some confusion concerning how the default package namespace should work. Currently, pugs does: % pugs -e '$main::foo=foo; say $foo' foo which contradicts S10, which states: The ::* namespace is not main. The default namespace for the main program is ::*Main. This turned out to be an oversight - but there was then confusion as to how one actually refers to variables in the ::*Main namespace, as if $Foo::bar looks up the ::Foo object and fetches $bar from it, then presumably $*Main::foo should look up the ::*Main object, and fetch $foo from it. However (from #perl6): autrijus Arathorn: when you see $Foo::bar, it means looking up the ::Foo object, then fetch $bar from it autrijus and ::Foo, just like %Foo, can be lexical or package scoped or global (%*Foo) autrijus to restrict the lookup to ::*Foo you can't use the ordinary qualifying syntax, I think. autrijus but I may be completely wrong Arathorn so it sounds as if to get the variable $bar from the global packagename ::*Foo (or just *Foo if disambiguation is not necessary), you'd use $*Foo::bar then. autrijus that may be the case, yes. autrijus $?Foo::bar means $?bar in Foo:: autrijus but $*Foo::bar can't mean $*bar in Foo:: autrijus because Foo:: will never contain a $*bar. autrijus so it must mean $bar in *Foo:: autrijus this is very weird. So the question is: what is the correct syntax for referring to package variables in the default namespace? Also, what is the correct syntax for referring to package variables in your 'current' namespace? $::foo? $?PACKAGENAME::foo? $::($?PACKAGENAME)::foo? %PACKAGENAME::foo? cheers, Matthew. -- Matthew Hodgson [EMAIL PROTECTED] Tel: +44 7968 722968 Arathorn: Co-Sysadmin, TheOneRing.net®
Re: Referring to package variables in the default namespace in p6
On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote: : Hi all, : : I've spent some of the afternoon wading through A12 and S10 trying to : thoroughly understand scope in perl 6, in light of the death of use vars : and the addition of class (as well as package module) namespaces. : : In the process I came up against some confusion concerning how the default : package namespace should work. Currently, pugs does: : : % pugs -e '$main::foo=foo; say $foo' : foo : : which contradicts S10, which states: : : The ::* namespace is not main. The default namespace for the main : program is ::*Main. : : This turned out to be an oversight - but there was then confusion as to : how one actually refers to variables in the ::*Main namespace, as if : $Foo::bar looks up the ::Foo object and fetches $bar from it, then : presumably $*Main::foo should look up the ::*Main object, and fetch $foo : from it. : : However (from #perl6): : : autrijus Arathorn: when you see $Foo::bar, it means looking up the ::Foo : object, then fetch $bar from it : autrijus and ::Foo, just like %Foo, can be lexical or package scoped or : global (%*Foo) : autrijus to restrict the lookup to ::*Foo you can't use the ordinary : qualifying syntax, I think. : autrijus but I may be completely wrong : Arathorn so it sounds as if to get the variable $bar from the global : packagename ::*Foo (or just *Foo if disambiguation is not necessary), : you'd use $*Foo::bar then. : autrijus that may be the case, yes. : autrijus $?Foo::bar means $?bar in Foo:: : autrijus but $*Foo::bar can't mean $*bar in Foo:: : autrijus because Foo:: will never contain a $*bar. : autrijus so it must mean $bar in *Foo:: : autrijus this is very weird. : : So the question is: what is the correct syntax for referring to package : variables in the default namespace? The * looks like a twigil but it isn't really. It's short for *::, 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.) : Also, what is the correct syntax for referring to package variables in : your 'current' namespace? $::foo? $?PACKAGENAME::foo? : $::($?PACKAGENAME)::foo? %PACKAGENAME::foo? That's currently: $OUR::foo though presumably $::($?PACKAGENAME)::foo would also work as a symbolic reference. I'm not sure whether $::foo is usefully distinct from $foo these days. It almost seems to imply that ::foo is in type space and we have to dereference it somehow. There's a sense in which :: only implies type space after a name. We somehow seem to have the situation where :: is simultaneously trying to be a leading sigil, a trailing sigil, and a separator. Larry
Re: Referring to package variables in the default namespace in p6
On Tue, 19 Jul 2005, Larry Wall wrote:
On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote:
:
: So the question is: what is the correct syntax for referring to package
: variables in the default namespace?
The * looks like a twigil but it isn't really. It's short for *::,
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.)
So, if I understand this correctly, the conclusion for referring to the
default program namespace is $*Main::foo - which is shorthand for
$*::Main::foo, which pulls the variable $foo out of the globally-rooted
namespace called Main. I'll plonk some tests into pugs to try to steer
towards that...
In terms of resolving non-fully-qualified namespaces, presumably
$Main::foo would work most of the time, assuming that you weren't
currently within any package/module/class namespace scopes called Main -
as S02 says 'the * may generally be omitted if there is no inner
declaration hiding the global name.'?
: Also, what is the correct syntax for referring to package variables in
: your 'current' namespace? $::foo? $?PACKAGENAME::foo?
: $::($?PACKAGENAME)::foo? %PACKAGENAME::foo?
That's currently:
$OUR::foo
right... I guess that goes with $MY:: and $OUTER:: in S06 and their
respective hash access methods.
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? :/
is being able to:
% perl6 -e '{ $*Main::foo = foo; } say $OUR::$foo'
really a feature? Or is OUR:: actually intended to include non-lexically
scoped package variables too as a special case?
I'm not sure whether $::foo
is usefully distinct from $foo these days. It almost seems to imply
that ::foo is in type space and we have to dereference it somehow.
There's a sense in which :: only implies type space after a name.
We somehow seem to have the situation where :: is simultaneously
trying to be a leading sigil, a trailing sigil, and a separator.
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.
I assume that I am correctly following your lead in referring to
package/module/class namespaces as 'type space' here...
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...
thanks hugely for the quick feedback :)
M.
