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.
I don't think there is one, unfortunately. Luckily we'll dodge the problem in most cases, since source modules will generally keep to themselves, in which case it's only explicit access to globals that'll be problematic. (And only *real*, explicit globals, since the implicit namespace partitioning scheme that's been discussed takes care of most 'global' variables)
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.
They don't overlap, so we're OK there.
*) 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.
Well... maybe. It's a really useful trick, though, and allows for a number of useful after-the-fact metaprogramming things. (But, then, I can see an argument that support for meta-anything isn't necessarily a good idea)
Objects can still fully override this if they want -- all method invocation does still go through the object's vtable.
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.
I don't think we've got any of those, so we're OK.
*) 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".
The problem there is deciding whether foo is $foo, @foo, or %foo, all of which may exist simultaneously. If they aren't named $foo, @foo, and %foo, but instead are all foo, then we're back to globs and globs are a place we don't want to be at. (Not to mention the cross-language issues you really run into, for languages that don't do a simple scalar/hash/array split, but use different basic classifications, or none at all) So even if we did force perl to do name mangling, we get other problems in return.
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)'.
Yep. But, then, from Python you won't be able to set $îné‚äOêl either, so I'm not sure it's that big a deal. ('specially since I'm not sure my mail client will let me either...) Besides, Python's OO and we all know global variables are evil things one doesn't use in OO code, right? :)
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...).
Alas, there will always be problems. We can make interoperability *possible*, but that doesn't mean we can make it *easy*. Some things are going to suck, regardless of what we do. (Besides, if sharing globals turns out to be a naming problem that's generally a pain to deal with, *and* languages don't want to bring in name aliasing, then globals like this will all have to be set via some sort of function/method API, and I think that's probably a good thing all around)
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.
Eh. Maybe, but that assumes a widespread usage of cross-module globals. That's pretty rare.
(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.
There's a limit to what we can do, though. We can provide the facilities and the semantics, but
*) 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. :)
You've avoided being mugged by all the people who have a really, really good reason (just ask them) to tie namespaces to do this one Really Important Thing that they can't otherwise do without it.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
