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

[TSa (Thomas Sandlaß)]

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