On Tue, Mar 07, 2006 at 02:53:39PM +0100, Leopold Toetsch wrote:
> 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 <[EMAIL PROTECTED]>
