Q: pdd21 - namespaces.pod
Leopold Toetsch
$P0 = find_global $P1, $S0
$P0 = find_global $S0
Find the variable $S0 in $P1 or the current namespace.
What about subroutines? Or should it return whatever is stored under the
given name?
Compile-time Creation
...
.HLL "Perl5", "perl5_group"
.namespace [ "Foo" ]
...
store_global "$x", $P0
.end
In this case, the "main" sub would be tied to Perl5 by the
".HLL" directive, so a Perl5 namespace would be created.
As this is storing into the current namespace, which I presume is
'Perl5::Foo', this would be equivalent to: '$Perl5::Foo::x'? That is the
'.HLL' automagically selects everything being in 'Perl5' namespace here.
Run-time Creation
...
store_global $P2, $S0, $P3
This is the same variable as above, but the 'store_global' with an
explicit namespace. As the namespace is now absolute, wouldn't that need
unshift $P2, 'Perl5'
before the 'store_global'? Or is the languages namespace prepended
automatically? How can some HLL access a different HLL namespace then?
Thanks for comments,
leo
Chip Salzenberg
> I've started implementing pdd21
"and there was much rejoicing" :-) Great questions, I know exactly why
you're asking them, and I'm thinking I need to amend pdd21 to include some
of the answers.
> but I got some more questions:
>
> $P0 = find_global $P1, $S0
> $P0 = find_global $S0
> Find the variable $S0 in $P1 or the current namespace.
>
> What about subroutines? Or should it return whatever is stored under the
> given name?
The *_global opcodes should use the untyped interface. (As they do now,
since now that's the only kind. :-))
So, if the sample is Perl code, $S0 will (presumably) contain a name with a
sigil, and Parrot won't translate anything; it will just use the namespace's
hash interface.
This choice means that grafting cross-language sub-namespaces into each
others' namespaces won't work right in the general case. (e.g. Don't try to
make a Python namespace 'foo' available in Perl as '%Foo::'.)
But that's OK; Parrot cross-HLL code isn't supposed to do that, it's
supposed to use item-by-item aliasing, either by hand or using the general
exporter.
It's hard enough to make explicit importation work across languages; we
don't need the *_global opcodes to handle cross-language too, we want them
to be fast & simple.
[The '$Perl5::Foo::x' example is elided as I think this answer obviates it.]
Moving on:
> ...
> .HLL "Perl5", "perl5_group"
> .namespace [ "Foo" ]
> ...
> store_global "$x", $P0
> .end
>
> In this case, the "main" sub would be tied to Perl5 by the
> ".HLL" directive, so a Perl5 namespace would be created.
Right.
> As this is storing into the current namespace, which I presume is
> 'Perl5::Foo'
Well, the leading 'perl5' is always lower case. :-) But yes.
> Run-time Creation
> ...
> store_global $P2, $S0, $P3
>
> This is the same variable as above, but the 'store_global' with an
> explicit namespace. As the namespace is now absolute, wouldn't that need
>
> unshift $P2, 'Perl5'
>
> before the 'store_global'? Or is the languages namespace prepended
> automatically? How can some HLL access a different HLL namespace then?
That's such a good question, it has a three-and-thre-quarters-part answer:
1. Effectively, from the user's point of view: Yes, the unshift is
implied.
2. Runtime efficiency and memory usage would suffer if we really did the
unshift. I suggest caching a pointer to the HLL base namespace in the
HLL info.
a. As with all optimizations, this cheats: It implies that users can't
switch out an HLL namespace after it's created. But in the specific
cases of the genuine root namespace and the top-level namespace for
entire HLLs, I'm OK with that.
3. Cross-language work won't use the *_global opcodes don't have to support
but rather, explicit namespace object manipulation.
a. The typed interface exists to enable cross-language work, and that
interface uses method names to specify type; none of this is a good
fit for the *_global opcodes, which have no way to specify type.
(We could make them know about types, but that'd be anti-huffman;
intra-HLL work is overwhelmingly more common than inter-HLL work.)
b. Users will need a way to get a pointer to the absolute root
namespace. An interpinfo code might work well for this. Then users
will do manual namespace navigation to reach the HLL they want. This
isn't exactly -automatic-, but though cross-HLL work should be easy
and supported, it does require thought and is relatively rare, so we
don't have to optimize it for brevity.
i. No namespace name should be privileged to mean something special
in the Parrot namespace code. For example, using [''] or ["\0"]
as a standard to mean "absolute root" is not OK. On the other
hand, weird_hll_namespace objects can do whatever they want....
Thanks for the good questions, I hope this answers them.
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
> Thanks for the good questions, I hope this answers them.
Thanks, yes. So I got a new one ;)
In which namespaces should Parrot store PMC methods and multi subs?
Currently Parrot occupies these namespaces:
__parrot_core ... buitin multisubs like '__add'
Integer ... all PMCs with methods are in a toplevel namespaces,
String with their class name
...
leo
Chip Salzenberg
> Chip Salzenberg wrote:
>
> >Thanks for the good questions, I hope this answers them.
>
> Thanks, yes. So I got a new one ;)
No rest for the wicked. :-)
> In which namespaces should Parrot store PMC methods and multi subs?
> Currently Parrot occupies these namespaces:
>
> __parrot_core ... buitin multisubs like '__add'
> Integer ... all PMCs with methods are in a toplevel namespaces,
> String with their class name
> ...
Working from first principles, and making some progress, I write (and invite
analysis of) these points:
1. The default target for 'newclass' must be inside the current HLL, or else
Parrot and Perl code can't both say 'newclass "Integer"'.
Confidence: HIGH
a. This implies that there should be a variant of newclass for global
classes. A 'newglobalclass' opcode is the most obvious solution, and
simultaneously the least elegant, because it implies that there will
be other *global* opcodes, and I don't like where that's going.
Alternatively, newclass could accept an optional starting namespace
parameter, which defaults to the current HLL namespace.
Confidence: HIGH in need for solution, LOW in actual solution
2. Therefore, class lookup must be two-level: the current HLL first, and the
global list.
Confidence: HIGH
a. Does this imply that we should allow users to see and modify a list
of namespaces to search for classes, a la $ENV{PATH}?
Confidence: LOW, but intriguing
3. Under the assumption that PMC names are supposed to map to HLL class
names (else what will?), it makes a lot of sense for newclass, the new
operator, etc. all to allow multi-level names.
Confidence: MEDIUM; it's possible that explicit namespace manipulation
could take the place of full keyed names here, and perhaps
also help solve the problem described in 1(a) above.
4. I'd like for global Parrot classes to live in a namespace other than the
root, and that name should be something users can count on so they can
do introspection (e.g. to detect name conflicts).
Let's call it "class".
Confidence: HIGH (cluttered roots are bad)
a. Just like the HLL namespace, it makes sense to cache this namespace
pointer, so we don't have to keep looking it up.
And a bonus policy point:
5. All root names (including root namespaces) that start with '_' shall be
designated now and forevermore to be something that users are not allowed
to count on (though of course exploration is always allowed).
So it's OK for us to leave the builtins in '__parrot_core', because I
don't have any better suggestion at the moment, and we can move them
later. Any users who depended on finding them there will have broken the
basic rule I just made up.
(Besides, the leading '_' should clue in anybody who's ever used C or
C++ that it's private, which is presumably what was intended anyway.)
--
Chip Salzenberg <ch...@pobox.com>