Some namespace notes
Jeff Clites
month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
> That does, though, argue that we need to revisit the global access
> opcodes. If we're going hierarchic, and we want to separate out the
> name from the namespace, that would seem to argue that we'd want it to
> look like:
>
> find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
>
> That is, split the namespace path from the name of the thing, and make
> the namespace path a multidimensional key.
I definitely agree that we should have separate slots for namespace and
name, as you have above. So I think the discussion boils down to
whether a namespace specifier is logically a string or an array of
strings.
Short version: I was originally going to argue for fully hierarchical
namespaces, identified as above, but after turning this over in my head
for a while, I came to the conclusion that namespaces are not
conceptually hierarchical (especially as used in languages such as
Perl5 and Java, at least), so I'm going to argue for a single string
(rather than an array) as a namespace identifier.
Here's my framing of the general problem. I think there are 3 basic
options:
1) No namespaces. That would mean we might have variables named
"Foo::Bar::baz", but to parrot that would just be a variable with a
funny name (it wouldn't infer any sort of nesting of variables or
namespaces).
2) Two-level namespaces. That would mean that parrot has the concept of
"look up variable 'baz' in namespace 'Foo::Bar'", but no concept of
nested namespaces--"Foo::Bar" is just a funny namespace name (no
nesting of namespaces inferred).
3) Full hierarchical namespaces. So parrot knows how to "look up
variable baz inside namespace Bar inside namespace Foo". Parrot would
never need to see the syntax ("::" v. "." v. whatever) used by
different languages to specify nested namespaces--their compilers would
assemble these as arrays, as in Dan's example above.
(Also, (2) v. (1) is what Tim was indicating with :
*{"Foo\0Bar\0Baz"}->{var};
or
*{"Foo\0Bar\0Baz\0var"};
in his post in the previous thread, I believe.)
I think that probably most agree that (1) is out--so the question is
(2) v. (3).
I think there are 2 considerations:
A) What does a hierarchy give us?
B) What kind of cross-language compatibility do we need?
As to (A), I don't think the hierarchy actually matters much. What I
mean is, that I don't think it's actually significant to say that the
namespace A::B::C is "inside" of the namespace A::B. For instance,
$A::B::C::var won't "fall back" to finding $A::B::var -- they're really
just separate namespaces which would have worked just the same if
they'd been called "ABC" and "AB" or "Foo" and "Bar". The hierarchy is
only used to conceptually organize things (for humans), not really at
runtime. Notably, this is the viewpoint taken by Java and I believe by
Perl5. (For instance, Java has a "com.sun.media.sound" namespace, but
not a "com" namespace.)
So unless I'm missing some uses of a hierarchy, I think that (A)
doesn't argue for (3) over (2), so it boils down to consideration (B).
For (B), what I mean is: Do we want the following to refer to the same
package/namespace:
in Perl:
use Foo::Bar::Baz;
in Java:
import Foo.Bar.Baz;
If we do, then I say we should go with (3), and use the array-based
method of specifying a namespace which Dan indicated above. Then, it's
up to the individual compilers to pick apart this syntaxes into the
same arrays: ['Foo', 'Bar', 'Baz']
On the other hand, maybe we don't want this. Maybe we want these to
refer to different packages/namespaces. In Perl, if I want to actually
instantiate a java.lang.String, maybe it's clearer to just really treat
the class name as "java.lang.String". I actually think it should be up
to the individual language implementers to decide if they want to
"normalize" during compilation to a common syntax for specifying
package names, but I think it makes more sense for them to _not_
normalize, and in Perl just "use java.lang.String" to pull in that Java
package.
So I'm arguing for (2), which says: Namespaces don't conceptually nest.
Now, that said, this really just argues that most languages actually
use 2-level namespaces in their syntax--that "Foo::Bar::Baz" doesn't
really indicate nesting. But, we can certainly _allow_ namespace
nesting--it just wouldn't have a one-line syntax. What I'm thinking of
here is having ops like this:
-----
# shortcut for lookup of "thingnane" in global namespace
find_global P1, "thingname"
-----
# lookup "thingname" in namespace "MyPackage::Foo"; really, this is:
find namespace "MyPackage::Foo" inside global namspace, and lookup
"thingname" in that, so it's still a shortcut
find_global P1, "MyPackage::Foo", "thingname"
-----
# here's an alternate, more explicit way to do the same thing. This
might be slower for a single lookup (the one-step method may be able to
optimize), but faster if you need to do multiple lookups, since you
have a direct reference to the namespace which you can re-use. It would
be up to the HLL compiler to decide which to use when.
# find "MyPackage::Foo" namespace inside global namespace
find_namespace P2, "MyPackage::Foo"
# find "thingname" using explicit namespace reference
find_global P1, P2, "thingname"
-----
# Here's how you could actually use nested namespaces
# find namespace in global namespace
find_namespace P2, "MyPackage::Foo"
# find namespace using explicit namespace reference
find_namespace P3, P2, "Boo:Bar::Baz"
# find "thingname" inside explicit namespace reference--doesn't really
matter that this namespace was looked up inside another
find_global P1, P3, "thingname"
-----
[So that's three find_global variants, and two find_namespace
variants--of course, some could have different names if that's
clearer.]
That is, you can nest namespaces if you want, but at the parrot level
there's no one-line syntax for that, and Perl5 and Java wouldn't use
this feature, and Perl6 probably wouldn't.
At the conceptual level, the reason that HLLs tend to use 2-level
namespace (rather than fully nested) is that really they are a means
for humans to coordinate at-a-distance, either (a) so that 2 people can
create classes or variables called "Foo" without conflict, because one
will be "com.jeff.Foo" and one will be "com.john.Foo", or (b) to keep
things such as CPAN organized conceptually. Once you have a namespace
you "own" (eg, com.YourCompany.YourDepartment), there's no need to
nest, since you can manage name conflict within your own namespace
(almost by definition).
So, that's my take on namespace nesting and syntax. Option (2) maps
better to how HLLs tend to think of and use namespaces, and can still
accommodate fully nested namespaces, if any language really needs them.
JEff
Dan Sugalski
>Here are some notes on namespaces, picking up a thread from about a month ago:
>
>On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
>
>>That does, though, argue that we need to revisit the global access
>>opcodes. If we're going hierarchic, and we want to separate out the
>>name from the namespace, that would seem to argue that we'd want it
>>to look like:
>>
>> find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
>>
>>That is, split the namespace path from the name of the thing, and
>>make the namespace path a multidimensional key.
>
>I definitely agree that we should have separate slots for namespace
>and name, as you have above. So I think the discussion boils down to
>whether a namespace specifier is logically a string or an array of
>strings.
>
>Short version: I was originally going to argue for fully
>hierarchical namespaces, identified as above, but after turning this
>over in my head for a while, I came to the conclusion that
>namespaces are not conceptually hierarchical (especially as used in
>languages such as Perl5 and Java, at least), so I'm going to argue
>for a single string (rather than an array) as a namespace identifier.
Here's my big, and in fact *only*, reason to go hierarchical:
We don't need to mess around with separator character substitution.
Other than that I don't much care and, as you've pointed out, most of
the languages don't really do a hierarchical structure as such. Going
hierarchical, though, means we don't have to do "::"/":"/"/"/whatever
substitutions to present a unified view of the global namespaces.
I'm thinking really hard about this at the moment, so this'd be a
good time to reconsider considering the problem. (And thanks much to
Jeff, whose message I've tacked this onto, for the set 'o things to
ponder)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Uri Guttman
DS> At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
>> Here are some notes on namespaces, picking up a thread from about a month ago:
>>
>>> That does, though, argue that we need to revisit the global access
>>> opcodes. If we're going hierarchic, and we want to separate out the
>>> name from the namespace, that would seem to argue that we'd want it
>>> to look like:
>>>
>>> find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
>>>
>>> That is, split the namespace path from the name of the thing, and
>>> make the namespace path a multidimensional key.
>>
>> I definitely agree that we should have separate slots for namespace
>> and name, as you have above. So I think the discussion boils down to
>> whether a namespace specifier is logically a string or an array of
>> strings.
>>
>> Short version: I was originally going to argue for fully
>> hierarchical namespaces, identified as above, but after turning this
>> over in my head for a while, I came to the conclusion that
>> namespaces are not conceptually hierarchical (especially as used in
>> languages such as Perl5 and Java, at least), so I'm going to argue
>> for a single string (rather than an array) as a namespace identifier.
DS> Here's my big, and in fact *only*, reason to go hierarchical:
DS> We don't need to mess around with separator character substitution.
DS> Other than that I don't much care and, as you've pointed out, most of
DS> the languages don't really do a hierarchical structure as such. Going
DS> hierarchical, though, means we don't have to do "::"/":"/"/"/whatever
DS> substitutions to present a unified view of the global namespaces.
i was musing on this too and back the fully hierarchal namespace
design. we won't have to worry about name separators except at
conversion time. and in p5 at least, the symtable is a real HoH tree and
you can pass around a section of it by reference or copy. that would be
so nasty with a joined string key thingy. i did plenty of that pseudo
multidim hash crap in my perl4 days. :) we have the technology to build
real hash tress so let's use it as it is the natural way a symtree
lives. going with a single key of a joined string doesn't seem to have
any benefits. i can't even see it being so much faster. also we can
always cache lookups in a single string hash for speedups.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Benjamin K. Stuhl
> At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
>> Short version: I was originally going to argue for fully hierarchical
>> namespaces, identified as above, but after turning this over in my
>> head for a while, I came to the conclusion that namespaces are not
>> conceptually hierarchical (especially as used in languages such as
>> Perl5 and Java, at least), so I'm going to argue for a single string
>> (rather than an array) as a namespace identifier.
It is probably worth pointing out that even in Perl5 namespaces
are implemented as though they were hierarchical. They're passed
around as strings ("Foo::Bar::baz"), but when a variable is
fetched (C<Perl_gv_fetchpv()> in gv.c), perl parses the string
as though it was a multidimensional key, with dimensions separated
by "::" "'". As Uri pointed out, this makes it easy to take and
pass around references to stashes; it also reduces memory usage,
since there is only one copy each of "Foo" and "Bar", regardless
of how many items are in %Foo::Bar:: .
Performance-wise, I would guesstimate that it's more-or-less a
wash between parsing strings and parsing multidimensional keys,
so as long as we precreate the keys (keep thm in a constant
table or something), I see no performance issues.
Just keep the variable's name separate from its namespace (as
codified in pdd06), and IMHO we should be golden with multidimensional
keys.
> Here's my big, and in fact *only*, reason to go hierarchical:
>
> We don't need to mess around with separator character substitution.
>
> Other than that I don't much care and, as you've pointed out, most of
> the languages don't really do a hierarchical structure as such. Going
> hierarchical, though, means we don't have to do "::"/":"/"/"/whatever
> substitutions to present a unified view of the global namespaces.
But we do need to worry about cross-language namespace collisions... :-D
-- BKS
Jeff Clites
A key part of my argument (and it's find if you understood this, and
disagree--just wanted to make sure that it was clear) is that I think
we shouldn't try to do any sort of cross-language unification. That is,
if we some day have a Parrot version of Java, and in Perl6 code I want
to reference a global created inside of some Java class I've loaded in,
it would be clearer to just reference this as
"java.lang.String.CASE_INSENSITIVE_ORDER", even inside of Perl6
code--rather than having to do something like
"java::lang::String::CASE_INSENSITIVE_ORDER". Parrot itself would be
completely ignorant of any concept of a separator character--these
would just be uninterpreted strings, and "foo::bar" and "foo.bar" would
be separate namespaces, whatever the language. I think it's confusing
to try to unify namespaces across languages, and doesn't buy us
anything. I think it's much cleaner to say "namespaces have names which
are arbitrary strings, and if you want to put colons or periods in the
name, so what--parrot doesn't care".
(That said, if the Perl6 creators and the Java-on-Parrot creators
decided that it _is_ good to try to unify their namespaces, they could
still do this at the compiler level--so maybe Perl6 would substitute
"." for "::" in namespace names at compile time. But parrot itself
wouldn't know or care. And, if the Python people decide it's better not
to try to unify with this mega-namespace, that's up to them.)
So I'm arguing here against a unified view of the global namespaces.
But, if we decide that's needed, then I definitely agree that it's best
to avoid having some magic separator character--much cleaner to treat
it as an array.
JEff
Jeff Clites
> Thus wrate Dan Sugalski:
>> At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
>>> Short version: I was originally going to argue for fully
>>> hierarchical namespaces, identified as above, but after turning this
>>> over in my head for a while, I came to the conclusion that
>>> namespaces are not conceptually hierarchical (especially as used in
>>> languages such as Perl5 and Java, at least), so I'm going to argue
>>> for a single string (rather than an array) as a namespace
>>> identifier.
...
> Performance-wise, I would guesstimate that it's more-or-less a
> wash between parsing strings and parsing multidimensional keys,
> so as long as we precreate the keys (keep thm in a constant
> table or something), I see no performance issues.
It turns out that it makes a big difference in lookup times--doing one
hash lookup v. several. I did this experiment using Perl5 (5.8.0):
Create a structure holding 1296 entries, each logically 12 characters
long--either one level of 12 character strings, or 2 levels of 6
character strings, or 3 levels of 4 character strings, or 4 levels of 3
character strings, and look up the same item 10 million times. Here is
the time it takes for the lookups:
1-level: 14 sec.
2-level: 20 sec.
3-level: 25 sec.
4-level: 32 sec.
Conclusion: It's faster to do one lookup of a single, longer string
than several lookups of shorter strings.
Of course, as Uri pointed out, even if we go with hierarchical
namespaces, we could implement these internally as a single-level hash,
behind the scenes, as an implementation detail and optimization.
JEff
Luke Palmer
My two cents: I don't care as long as we can toss symbol tables around
as PMCs, and replace symbol tables with different (alternately
implemented) PMCs. I think it's possible to do this using a clever
ordered hash scheme even if we go one level, but it's something to keep
in mind.
Luke
> JEff
>
Tim Bunce
* Basics:
Parrot uses nested hashes for namespaces (like perl does).
The high-level language splits namespace strings using whatever
its separator is ('::', '.' etc) to generate an array of strings
for the namespace lookup.
* Relative roots:
Namespace lookup starts from a 'root' namespace (think root directory).
Here the P2 argument holds the root namespace to start the lookup from:
find_global P1, P2, ['global', 'namespace', 'hierarchy'], "thingname"
If it's null then the interpreters default root namespace is used.
This scheme allows chroot() style shifting of the effective root.
(It's a key part of how the perl Safe module "works", for example.)
* Per-language root:
Each HLL could use a 'root' that's one level down from the true root.
Using a directory tree for illustration:
/perl/Carp/carp perl sees "Carp" at top level
/java/java/lang/... java sees "java" at top level
* Backlinks:
/perl/main -. "main" points back to "perls own root"
^------' (so "$main::main::main::foo" works as it should)
/perl/parrot -. "parrot" points back to true root
^-------------'
* Accessing namespace of other languages:
Given the above, accessing the namespace of other languages is as simple as:
/perl/parrot/java/java/lang/String/...
eg "$parrot::java::java::lang::String::CASE_INSENSITIVE_ORDER" for perl
and "parrot.perl.Carp.carp" for Java (perhaps, I don't claim to know any Java)
* Summary:
- Nested hashes allow chroot() style shifting of the root.
- That requires the 'effective root' to be passed to find_global.
- Each HLL could have it's own 'root' to avoid name clashes.
- Backlinks can be used to provide access to other HLL namespaces.
- This combination of unification (all in one tree) and isolation
(each HLL has a separate root) offers the best of all worlds.
Tim.
Leopold Toetsch
> Here's my proposal:
> * Basics:
> Parrot uses nested hashes for namespaces (like perl does).
> * Relative roots:
> Namespace lookup starts from a 'root' namespace (think root directory).
> Here the P2 argument holds the root namespace to start the lookup from:
> find_global P1, P2, ['global', 'namespace', 'hierarchy'], "thingname"
I like that except: *again* above syntax sucks.
find_global P1, P2 ['global'; 'namespace'; 'hierarchy'; "thingname" ]
P2 can be a namespace PMC or the interpreter itself.
find_global P3, P2 ['global'; 'namespace'; 'hierarchy' ]
returns another namespace, and ...
find_global P1, P3 [ "thingname" ]
is the same, as the first.
The original syntax would need heavy modifications in the assembler, the
latter fits nicely.
> Tim.
leo
Tim Bunce
Sure. Sounds good.
(I'm not well placed to talk about syntax as I've not yet written any
parrot code, though than may be about to change, it's the principles of
a unified hierarchy, chroot, and backlinks that's important.)
Tim.
Dan Sugalski
>Tim Bunce <Tim....@pobox.com> wrote:
>> Here's my proposal:
>
>> * Basics:
>
>> Parrot uses nested hashes for namespaces (like perl does).
>
>
>> * Relative roots:
>
>> Namespace lookup starts from a 'root' namespace (think root directory).
>> Here the P2 argument holds the root namespace to start the lookup from:
>
>> find_global P1, P2, ['global', 'namespace', 'hierarchy'], "thingname"
>
>I like that except: *again* above syntax sucks.
>
> find_global P1, P2 ['global'; 'namespace'; 'hierarchy'; "thingname" ]
No. The thing will be a separate parameter.
>
>The original syntax would need heavy modifications in the assembler, the
>latter fits nicely.
We can cope. The assembler needs a good kick with regards to keyed
stuff anyway, I expect, and we're going to need this for constructing
keys at runtime, something we've not, as yet, addressed.
Dan Sugalski
>A key part of my argument (and it's find if you understood this, and
>disagree--just wanted to make sure that it was clear) is that I
>think we shouldn't try to do any sort of cross-language unification.
I saw that and wasn't really looking to deal with it, but I
should've. I think we should have the potential for cross-language
unification. It shouldn't be obligatory, but it should be easy, and I
think we're going to see perl 5, perl 6, ruby, and python at least
sharing a global namespace once we get things going sufficiently.
Dan Sugalski
>Here's my proposal:
I like it all except for the backlink part, and that only because I'm
not sure the names are right. I'm tempted to use reasonably
unavailable characters under the hood (yeah, I'm looking at NUL
(ASCII 0) and maybe SOH (ASCII 1) for language root and global root).
Otherwise it looks good, and I think it's the way to be going.
Languages can have the option of sharing a common root if they so
choose, and set their search paths, since we're going to allow that
sort of thing with nested namespaces. The default global space can be
a two-level nest with the language level coming before the generic
one in the search space.
Leopold Toetsch
> At 12:49 PM +0100 1/16/04, Leopold Toetsch wrote:
>>
>> find_global P1, P2 ['global'; 'namespace'; 'hierarchy'; "thingname" ]
> No. The thing will be a separate parameter.
Why? Nested keys get you down the key chain until there is no more key.
This can be a variable (above case) or another namespace PMC. Above
lookup can be totally cached. When "thingname" is separate at least 2
hash lookups are necessary. Or if a separate "thingname" is there just
append it - should be equivalent.
>>The original syntax would need heavy modifications in the assembler, the
>>latter fits nicely.
> We can cope. The assembler needs a good kick with regards to keyed
> stuff anyway, I expect, and we're going to need this for constructing
> keys at runtime, something we've not, as yet, addressed.
We have:
$ cat k.pasm
new P1, .PerlHash
new P2, .PerlString
set P2, "hello\n"
set P1["b"], P2
new P3, .PerlHash
set P3["a"], P1
set P5, P3["a"; "b"] # HoH access by key cons
print P5
new P6, .Key
set P6, "a"
new P7, .Key
set P7, "b"
push P6, P7
set P5, P3[P6] # fully dynamic HoH access
print P5
end
$ parrot k.pasm
hello
hello
leo
Larry Wall
it wasn't pleasant. I think aliases (symlinks) work much better in
a hierarchy. So do inner packages, modules, and classes, which we
plan to have in Perl 6. And package aliasing will be the basis for
allowing different versions of the same module to coexist. And if
Parrot makes people put /perl/parrot/java on the front of Java names,
the first thing people will do is to alias them all to /java.
Larry
Peter Haworth
> I think we shouldn't try to do any sort of cross-language unification.
> That is, if we some day have a Parrot version of Java, and in Perl6 code I
> want to reference a global created inside of some Java class I've loaded
> in, it would be clearer to just reference this as
> "java.lang.String.CASE_INSENSITIVE_ORDER", even inside of Perl6 code--
> rather than having to do something like
> "java::lang::String::CASE_INSENSITIVE_ORDER". Parrot itself would be
> completely ignorant of any concept of a separator character--these would
> just be uninterpreted strings, and "foo::bar" and "foo.bar" would be
> separate namespaces, whatever the language.
What about languages which have the same separator, such as '::' (perl5,
perl6, ruby) or '.' (java, python)? They are going to be unified either way.
> I think it's confusing to try to unify namespaces across languages, and
> doesn't buy us anything.
Without namespace unification, how else are you going to even specify
File::Spec from java, or java.lang.string from perl5? We can obviously
invent suitable syntax for perl6, so that it can cope with arbitrarily named
packages, but we don't have that luxury with most of the other languages we
want to support.
Then the question becomes, "What about namespace clashes?", which Tim has
already addressed.
--
Peter Haworth p...@edison.ioppublishing.com
"Perl 5's goal was to make easy things easy, and hard things possible.
We want Perl 6 to make easy things trivial, hard things easy,
and impossible things merely hard."
-- Damian Conway, _Linux magazine_ 2003-04
Jeff Clites
> On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote:
>> I think we shouldn't try to do any sort of cross-language unification.
>> That is, if we some day have a Parrot version of Java, and in Perl6
>> code I
>> want to reference a global created inside of some Java class I've
>> loaded
>> in, it would be clearer to just reference this as
>> "java.lang.String.CASE_INSENSITIVE_ORDER", even inside of Perl6 code--
>> rather than having to do something like
>> "java::lang::String::CASE_INSENSITIVE_ORDER". Parrot itself would be
>> completely ignorant of any concept of a separator character--these
>> would
>> just be uninterpreted strings, and "foo::bar" and "foo.bar" would be
>> separate namespaces, whatever the language.
>
> What about languages which have the same separator, such as '::'
> (perl5,
> perl6, ruby) or '.' (java, python)? They are going to be unified
> either way.
Not necessarily. Each language has a choice, at compile-time, of what
separator to pass to the parrot API. For instance, even though I type
"Foo::Bar" in my perl5 code, it's possible that the perl5 compiler
passes "Foo+++Bar" on to parrot. So each language, via its compiler,
has a choice of what it wants to do: unify, explicitly avoid
unification, or not care. My point is that parrot shouldn't force the
unification, but rather let each language choose its policy.
>> I think it's confusing to try to unify namespaces across languages,
>> and
>> doesn't buy us anything.
>
> Without namespace unification, how else are you going to even specify
> File::Spec from java
import java.lang.reflect.*;
Class.forName("File::Spec");
> , or java.lang.string from perl5?
bless $ref, "java.lang.String";
> We can obviously invent suitable syntax for perl6, so that it can cope
> with arbitrarily named packages, but we don't have that luxury with
> most of the other languages we want to support.
I believe that most languages will have similar reflection API; if not,
we can add such API--languages which didn't previously have all of the
features which parrot provides either don't get all of those features,
or will need to take advantage of them via new API.
> Then the question becomes, "What about namespace clashes?", which Tim
> has
> already addressed.
We could certainly do some sort of language-specific prefixing, as Tim
suggested, but it seems that we are then going to trouble to unify,
only to immediately de-unify. Certainly, a random Java programmer
shouldn't have to worry about naming a class so that it doesn't
conflict with any class in any other language in the world--that's
silly, especially since this Java programmer may not even know about
parrot. (But it matters, if later someone wants to run his code on top
of parrot.) If we use per-language prefixing, then I'm certainly going
to have to be aware of what language is "hosting" a given class, and so
it seems natural to instead just use that class name as I would expect
it to be written--"java.lang.String" for Java, for example.
And again, one of my basic points here is that although namespace
nesting could be useful for some things (maybe), it isn't what's going
on in most languages anyway. For instance, Java does not have nested
namespaces--it just happens to have a convention for namespace naming
which involves dots, and also uses a dot as the separator between a
namespace name and the variable or class name. (Though I suppose
there's really 2 separate, but related, issues--how namespace names are
represented internally, and whether these names imply namespace
nesting.)
JEff
Luke Palmer
> We could certainly do some sort of language-specific prefixing, as Tim
> suggested, but it seems that we are then going to trouble to unify,
> only to immediately de-unify. Certainly, a random Java programmer
> shouldn't have to worry about naming a class so that it doesn't
> conflict with any class in any other language in the world--that's
> silly, especially since this Java programmer may not even know about
> parrot. (But it matters, if later someone wants to run his code on top
> of parrot.) If we use per-language prefixing, then I'm certainly going
> to have to be aware of what language is "hosting" a given class, and so
> it seems natural to instead just use that class name as I would expect
> it to be written--"java.lang.String" for Java, for example.
>
> And again, one of my basic points here is that although namespace
> nesting could be useful for some things (maybe), it isn't what's going
> on in most languages anyway. For instance, Java does not have nested
> namespaces--it just happens to have a convention for namespace naming
> which involves dots, and also uses a dot as the separator between a
> namespace name and the variable or class name. (Though I suppose
> there's really 2 separate, but related, issues--how namespace names are
> represented internally, and whether these names imply namespace
> nesting.)
But in fact, one of Perl 6's key features depends on heirarchical
namespaces: namespace aliasing. And then if the Java programmer
accidentally named a class the same a some perl module (unlikely,
because you probably won't see Perl with a org::bazbar::Foo module),
Perl is able to move that namespace somewhere else to make room for
another conflicting module.
Luke
Tim Bunce
>
> >Then the question becomes, "What about namespace clashes?", which Tim
> >has already addressed.
>
> We could certainly do some sort of language-specific prefixing, as Tim
> suggested, but it seems that we are then going to trouble to unify,
> only to immediately de-unify. Certainly, a random Java programmer
> shouldn't have to worry about naming a class so that it doesn't
> conflict with any class in any other language in the world--that's
> silly, especially since this Java programmer may not even know about
> parrot.
I think you missed the part where I said that each language has it's
own root which is actually below the root of the unified namespace.
The namespaces of other languages are reached via a backlink/symlink
kind of thing so they appear to be within the namespace of the
language being used.
> it seems natural to instead just use that class name as I would expect
> it to be written--"java.lang.String" for Java, for example.
In Java you would write "java.lang.String", naturally, and in Perl
you'd write "parrot::java::java.lang.String". As per the example I
gave previously. Take another look.
Tim.
Larry Wall
: In Java you would write "java.lang.String", naturally, and in Perl
: you'd write "parrot::java::java.lang.String".
That's okay if it's a string being interpreted by the appropriate
code, but as a Perl 6 name it won't wash. That's gonna try to call
the .lang method on the parrot::java::java class, and the String
method on the result of that.
(Unless, of course, you define a parrot::java::java macro to mangle
subsequent Perl 6 syntax. But that seems awfully hackish. And the
parrot::java namespace might not let you define the macro there in
the first place...)
Larry
Tim Bunce
Ah, no, it was simply a typo, I meant: parrot::java::java::lang::String
Tim.