On Sep 22, 2004, at 8:13 PM, Dan Sugalski wrote:
At 7:32 PM -0700 9/22/04, Jeff Clites wrote:
One problem: Some languages (Scheme, for example, and arguably C) have a unified namespace for subs and variables. What to do there?
The easiest thing would be to allow the languages to store into multiple sections at once, or leave it to them to do the right thing as they need to.
The risk is that if they store into both, then setting a variable in Scheme code might blow away a sub in perl, and other than that it seems you'll have big-time ambiguity. But I don't know of an obvious solution.
Either way works OK for me, since neither Scheme nor C are really our target languages.
Well, my point here is that namespace semantics varies a lot between languages, and quite reasonably people seem to want to target a lot of different languages to Parrot, besides just Perl/Python/Ruby. And I'm not sure where Python and Ruby stand, in terms of sub/variable name overlap.
*) Sub and method names *will* collide, so be careful there.
I'm not sure that they will.
I'd really, *really* rather they did. Not because I'm up for collisions (I'm not) but because if you *do* leave methods in namespaces it allows you to do all sorts of very interesting things with lexically overlaid namespaces.
To me, it doesn't make sense to muddle basic semantics to allow tricks. In particular, for method invocations on objects, it makes sense that the lookup is very directly "object to class, lookup method in class", rather than "object to class, get class name, lookup method in global namespace". There's an efficiency issue, and the latter precludes truly anonymous classes (since they should have no name with which to do a lookup). I tend to think of this as "classes live in namespaces, methods live in classes"--and of course anonymous classes aren't stored in a namespace, but are only usable via a reference to the class (like lexical v. global variables).
[Side note: Oh, and of course that reminds me--class names might need to be their own section of the namespace, or maybe they do just live in the, uh, namespace-namespace. My worry here is that the lookup API should really know the type of thing it's looking for--that is, have ops like lookupsub v. lookupvariable v. lookupnamespace--and it could be awkward if there is one that might return a namespace or might return a class, because those two things would have at least somewhat different API.]
And for existing libraries in languages which allow subs and methods with the same name, we can't retroactively change it--it's too late to be careful. But again, I'm not sure what it means to have a sub "in" a class, so they might just automatically stay out of each other's way. (For example, you could say Java had only methods, no functions, and Perl5 has only functions, no "real" methods.)
*) If a language wants different types of variables to have the same name, it has to mangle the names. (So you can't have an Array, a String, and an Integer all named Foo) The only language I know of that does this is Perl, and we just need to include the sigil as part of the name and we're fine there.
This seems antithetical to cross-language functionality.
Why? Not to be snarky here, I'm curious.
Just that if I set a global "$foo = 5" in Perl, I'd want to be able to change it from Python as, "foo = 5". From Python, I can't set it using "$foo = 5", since that isn't syntactically valid in Python, and it's no fun at all to have to do something introspective like, 'setValueOfGlobal("$foo", 5)'.
For me, I want to be able to load some compiled bytecode module, and not care what language it was written in. That's the goal of a generic object runtime. If the module's docs say, "set the global 'foo' to control...", then I'd want to do that in a way that is natural for whatever language I'm using ($foo in Perl, foo in Python...).
Strictly speaking, the names can be anything, which is fine. Nulls, control characters, punctuation, grammatically incorrect Bengali insults... we don't put any limits on 'em. And the only place that it makes any difference at all is when you're either doing the equivalent of C's extern or explicitly walking the namespace. In the latter case you ought to be ready for anything (since with Unicode I fully expect to see the full range of characters in use) and in the former case, well... you ought to be ready for anything since Unicode's going to put the full range of characters into use. :)
Sure, that fine--there will certainly be cases where one language allows variable names that another can't access "naturally", or maybe even at all. But in the Perl case, we'd end up having _all_ variable names turning out illegal in Python (and I suppose Ruby), which seems bad.
(Though it's somewhat academic. Besides leading to globs, and we *so* don't want to go there, Larry's declared that perl variable names include the sigil)
Of course, I'm not talking about Perl, I'm talking about Parrot. How it's thought of at the language level doesn't have to translate simplistically to the runtime level. In particular, Parrot cares about cross-language continuity, but Perl doesn't.
*) Namespaces, by default, support notifications.
What does that mean? Notification of what?
Inserts, deletes, and changes, possibly fetches too. Instrumentation. The notification system will allow code to watch for particular events happening to PMCs, and this is a good place to start. (Not to mention that the first thing anyone seems to want to do when they get down into the guts is tie namespaces)
Interesting. I feel no need to tie namespaces--I guess it's just me, tied hashes seem to be enough. :)
JEff
