develooper Front page | perl.perl6.language | Postings from July 2005

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

Thread Previous | Thread Next
Matthew Hodgson
July 21, 2005 04:15
Re: Referring to package variables in the default namespace in p6
Message ID:
On Thu, 21 Jul 2005, "TSa (Thomas SandlaƟ)" wrote:

> 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 =; # look for param type info

Okay; if this is how $::foo works, then it makes a whole lot of sense :)

>> Or is it an attempt to dereference the disambiguated type Foo?
> What is the use of reference to a type?

I have no idea - I was going on the basis of Larry's comment concerning 
$::Foo looking a bit like an attempt to dereference ::Foo.

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

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

Oops - the double negative was a typo there; apologies...  even then, I 
think I understand that you agree that $::foo simply means an outwards 
search of your current namespace scope for a variable called $foo.

> Sorry if that wasn't clear initially. But I hope the above rants
> clarify what I mean.

I hope that i'm on the right page now - thank you for taking the time to 
clarify :)

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

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.  Otherwise 
the two $::... forms would be horribly confusingly different in their 
behaviour, and I (and other future legions of newbies) would despair. :)

thanks again;

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About