Symbolic dereferentiation of magical variables

18 views
Skip to first unread message

Ingo Blechschmidt

unread,
Aug 20, 2005, 6:33:03 PM8/20/05
to perl6-l...@perl.org
Hi,

S02 says:
our $a; say $::("a"); # works

my $a; say $::("a"); # dies, you should use:
my $a; say $::("MY::a"); # works

How can I use symbolic dereferentiation to get $?SELF, $?CLASS,
::?CLASS, %MY::, etc.?

say $::('$?SELF'); # does this work?
say $::('MY::$?SELF'); # or this?


Also, is $::! valid syntax? (Or am I required to write this as
$::("!")?)


--Ingo

--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon! |

Larry Wall

unread,
Aug 21, 2005, 10:23:34 AM8/21/05
to perl6-l...@perl.org
On Sat, Aug 20, 2005 at 10:33:03PM +0000, Ingo Blechschmidt wrote:
: Hi,
:
: S02 says:
: our $a; say $::("a"); # works
:
: my $a; say $::("a"); # dies, you should use:
: my $a; say $::("MY::a"); # works

That looks like somebody's relic of Perl 5 thinking. Personally,
I don't see why the second one should die. I was kind of hoping
that symbolic lookups would include lexicals in Perl 6, unlike in
Perl 5. Then you use MY or OUR to force it one way or the other.
An unqualified lookup should find exactly the same symbol at run-time
that the compiler would find at compile time (though with non-strict
semantics on undeclared globals regardless of lexical strictness,
since the whole point of differentiating $::() notation from ${}
notation is to get rid of "use strict refs"). Also remember that
leading :: in general doesn't imply "main" as it does in Perl 5.

: How can I use symbolic dereferentiation to get $?SELF, $?CLASS,

: ::?CLASS, %MY::, etc.?
:
: say $::('$?SELF'); # does this work?

Probably not, since the ::() notation doesn't want sigils in the key,
and you have to say

$?::('SELF')

to have any hope of it working. On the other hand

%MY::<$?SELF>

might get you the symbol out of the symbol table hash, unless $?SELF
is too macro-y for that. $? variables aren't required to have
a dynamically lookupable meaning at run time, since their native
dynamic context is the compiler, not the run-time.

: say $::('MY::$?SELF'); # or this?

No, we don't currently allow sigils after ::. But maybe we could have
some quoting mechanism to allow it:

say $::('MY::<$?SELF>'); # or this?

: Also, is $::! valid syntax? (Or am I required to write this as
: $::("!")?)

I suspect :: after a sigil is always a no-op unless it's followed by
parens (and maybe <>, if we allow sigil lowering, which would also
give us:

$OUTER::OUTER::<$_>

and such.) I think I like the option lowering the sigil to the key.
Maybe the outer sigil is meaningless in that case, and it's just

OUTER::OUTER::<$_>

But if we say that any package/type name can tagmemically function
as a hash if you use like one, then the last :: can go too:

OUTER::OUTER<$_>
OUTER::OUTER{'$_'}

Though we're getting close to confusing this notation with

%OUTER::OUTER::{'$_'}

which looks similar, but (if we take the Perl 5 meaning) doesn't
do :: splitting on the key. In other words, this would also get
to OUTER::OUTER<$_>:

OUTER{'$OUTER::_'}

because it's accessing through the package as a hash and does further
:: breakdown. But this wouldn't work:

%OUTER::{'$OUTER::_'}

because it's accessing through the actual symbol table hash, which doesn't
have any such symbol as one of its keys.

That's an awfully subtle distinction, though. I think OUTER::OUTER's
symbol table hash needs a better name than %OUTER::OUTER. Maybe it's
named OUTER::OUTER<%OUR> or OUTER::OUTER::<%MY> or some such.
Which makes me think that Perl 5's %FOO::{'name'} symbol table
notation is really bogus, because %OUTER:: doesn't really refer to a
single symbol table in Perl 6, but the starting place for a symbol
search that may span several symbol tables. At least, that's how
I've been thinking of it. Maybe we nail OUTER down to one MY and
just use OUTER.findsym('$x') if that's what we mean. But then we
get bad interactions if someone says

FOO.findsym('$x')

on a class that defines its own findsym method. Or maybe that's
a feature. Or maybe only pseudo classes that resolve to MY variants
have a findsym method. ENOCAFFEINE.

Larry

Ingo Blechschmidt

unread,
Aug 22, 2005, 4:51:53 PM8/22/05
to perl6-l...@perl.org
Hi,

Larry Wall wrote:
> On Sat, Aug 20, 2005 at 10:33:03PM +0000, Ingo Blechschmidt wrote:
> : S02 says:
> : our $a; say $::("a"); # works
> :
> : my $a; say $::("a"); # dies, you should use:
> : my $a; say $::("MY::a"); # works
>
> That looks like somebody's relic of Perl 5 thinking. Personally,
> I don't see why the second one should die. I was kind of hoping
> that symbolic lookups would include lexicals in Perl 6, unlike in
> Perl 5. Then you use MY or OUR to force it one way or the other.

I like that very much! :)

> : How can I use symbolic dereferentiation to get $?SELF, $?CLASS,
> : ::?CLASS, %MY::, etc.?
> :
> : say $::('$?SELF'); # does this work?
>
> Probably not, since the ::() notation doesn't want sigils in the key,
> and you have to say
>
> $?::('SELF')
>
> to have any hope of it working. On the other hand
>
> %MY::<$?SELF>
>
> might get you the symbol out of the symbol table hash,

ok.

> unless $?SELF is too macro-y for that. $? variables aren't required
> to have a dynamically lookupable meaning at run time, since their
> native dynamic context is the compiler, not the run-time.

Makes perfect sense.

>
> : say $::('MY::$?SELF'); # or this?
>
> No, we don't currently allow sigils after ::.

I took that straight from S02 :):
> All symbolic references are done with this notation:
>
> $foo = "Foo";
> $foobar = "Foo::Bar";
> $::($foo) # package-scoped $Foo
> $::("MY::$foo") # lexically-scoped $Foo
> $::("*::$foo") # global $Foo
> $::($foobar) # $Foo::Bar
> $::($foobar)::baz # $Foo::Bar::baz
> $::($foo)::Bar::baz # $Foo::Bar::baz
> $::($foobar)baz # ILLEGAL at compile time (no operator baz)

> and such.) I think I like the option lowering the sigil to the key.
> Maybe the outer sigil is meaningless in that case, and it's just
>
> OUTER::OUTER::<$_>
>
> But if we say that any package/type name can tagmemically function
> as a hash if you use like one, then the last :: can go too:
>
> OUTER::OUTER<$_>
> OUTER::OUTER{'$_'}

I like those, especially as we've said that the sigils are part of the
variable name.

> Though we're getting close to confusing this notation with
>
> %OUTER::OUTER::{'$_'}
>
> which looks similar, but (if we take the Perl 5 meaning) doesn't
> do :: splitting on the key. In other words, this would also get
> to OUTER::OUTER<$_>:
>
> OUTER{'$OUTER::_'}
>
> because it's accessing through the package as a hash and does further
> :: breakdown. But this wouldn't work:
>
> %OUTER::{'$OUTER::_'}
>
> because it's accessing through the actual symbol table hash, which
> doesn't have any such symbol as one of its keys.
>
> That's an awfully subtle distinction, though. I think OUTER::OUTER's
> symbol table hash needs a better name than %OUTER::OUTER. Maybe it's
> named OUTER::OUTER<%OUR> or OUTER::OUTER::<%MY> or some such.

Makes sense.

> Which makes me think that Perl 5's %FOO::{'name'} symbol table
> notation is really bogus, because %OUTER:: doesn't really refer to a
> single symbol table in Perl 6, but the starting place for a symbol
> search that may span several symbol tables.

If we go with these changes, this functionality (starting place for a
search) would be available by using

Foo::Bar<$symbol_to_lookup>; # right?

Larry Wall

unread,
Aug 22, 2005, 5:17:59 PM8/22/05
to perl6-l...@perl.org
On Mon, Aug 22, 2005 at 10:51:53PM +0200, Ingo Blechschmidt wrote:
: If we go with these changes, this functionality (starting place for a

: search) would be available by using
:
: Foo::Bar<$symbol_to_lookup>; # right?

Presumably, though Foo::Bar differs from OUTER in that, for packages,
the only fallback place to look is *. We don't automatically scan
Foo after Foo::Bar, for instance. Maybe there could be some way
for Foo::Bar to delegate to Foo if it likes, though. Sort of an
inside-out import. But we've got along fine without that in Perl 5,
so I'm not going to mandate it in the base language unless we see
some really good uses for it. In general we should encourage outer
classes to share with inner classes via lexical scoping rather than
package scoping, I expect.

Larry

TSa

unread,
Sep 21, 2005, 7:15:32 AM9/21/05
to perl6-l...@perl.org
HaloO Larry,

you wrote:
> On Mon, Aug 22, 2005 at 10:51:53PM +0200, Ingo Blechschmidt wrote:
> : If we go with these changes, this functionality (starting place for a
> : search) would be available by using
> :
> : Foo::Bar<$symbol_to_lookup>; # right?
>
> Presumably, though Foo::Bar differs from OUTER in that, for packages,
> the only fallback place to look is *. We don't automatically scan
> Foo after Foo::Bar, for instance.

Just for the records: this implies an asymmetry between bareword
outwards scans and infixed :: scans. The latter imply a prefixed
*:: while the former don't, right? Or do you mean there's a single
attempt to get Bar from the innermost Foo and only if *that* fails
to fall back to *::Foo::Bar instead of scanning on outwards for
candidates for Foo to query for Bar and eventually reaching the
root and ultimately fail there.

Or not even a single attempt? This would then behave like the UNIX
shells I've encountered so far. That is if you have $HOME/bin in
your $PATH and two subdirs $HOME/bin/foo and $HOME/bin/bar which are
not in $PATH but each contain different version of some prog then
neither foo/prog nor bar/prog works.

<weird>
Or we interpret
1) Foo::Bar and
::Foo::Bar as the single, innermost, outer access attempt
2) *::Foo::Bar as the lazy outwards scan towards root
3) **::Foo::Bar as eager outwards access that is forced to start from
the root of the namespace

In case 1) the ::Foo::Bar form is only needed to defer the
definedness contraint while compiling or to disambiguate.
Well, I guess infix wildcards *::Foo::*::Bar are then even
to weird for this weirdness of mine :)
</weird>

> Maybe there could be some way
> for Foo::Bar to delegate to Foo if it likes, though. Sort of an
> inside-out import. But we've got along fine without that in Perl 5,
> so I'm not going to mandate it in the base language unless we see
> some really good uses for it.

One that comes to mind is in providing a sandboxed environment
without resorting to replicating the Perl6 root namespace environment.
When you know that a boxed module needs a Foo with a certain structure
you just provide that---easy enough. But if then the code you are
wrapping happend to access the Bar from Foo with the oververbose
syntax Foo::Bar this lookup suddenly warps out of the sandbox into
the actual root environment of the interpreter...


> In general we should encourage outer
> classes to share with inner classes via lexical scoping rather than
> package scoping, I expect.

Isn't that mixing access control in an unfortunate way with the
namespace manouvering syntax? OTOH, I hear me saying that privacy
comes from hiding...
--
$TSa.greeting := "HaloO"; # mind the echo!

Reply all
Reply to author
Forward
0 new messages