Hi @chip,
1)
Namespace Opcodes
add_namespace $P0, $P1
The opcode signature looks a bit strange to me, especially when compared
to the 'add_namespace' method. Is the namespace name implied? And there
is of course again the question where to add the namespace: relative to
HLL or absolute at namespace root.
The relative to HLL:: or absolute issue applies to 'get_namespace $P1'
too. OTOH the aliasing example explicitely includes 'perl6' as toplevel
namespace component. I'm missing some consistency here. Are only
{find,store}_global relative to 'HLL::'?
2)
Default Namespace
The default namespace PMC will implement Parrot's current behavior.
The current implementation allows a nested namespace and a variable to
have the same name (via the hack of prepending "\0" to namespace names).
Assuming that this hack should go away, I see two ways to continue
implementation:
a) Parrot's default namespace is untyped (raw). This means that a
variable/subroutine can't have the same name as a namespace. This could
break existing code.
b) Otherwise, Parrot's namespace is (half-)typed, at least namespace and
variable/sub are allowed to coexist with the same name. [1]
3) Parrot's internal namespace needs a name ('parrot', 'core' or whatever).
4) Where are all the Parrot libraries living: PGE, Getopt, Data, Digest,
...? Below the 'parrot' namespace? Toplevel? 'Lib'?
5) Has the namespace root a name?
$P0 = ns.'name'()
$S0 = join '::', $P0 # '::parrot::Foo'
or should the toplevel be excluded by 'name'?
Thanks for clarification,
leo
[1] This needs 2 storage slots per hash bucket, at least one more
indirection to access items. A fully typed namespace with 4 slots (raw,
namespace, var, sub) is then not more complicated to implement.
