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
From:
=?ISO-8859-1?Q?=22TSa_=28Thomas_Sandla=DF=29=22?=
Date:
July 21, 2005 02:48
Subject:
Re: Referring to package variables in the default namespace in p6
Message ID:
42DF6F45.5070909@orthogon.com
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Ɵ)



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About