On Sep 23, 2004, at 9:53 AM, Dan Sugalski wrote:
At 12:06 AM -0700 9/23/04, Jeff Clites wrote:On Sep 22, 2004, at 8:13 PM, Dan Sugalski wrote:
At 7:32 PM -0700 9/22/04, Jeff Clites wrote:
*) 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.
Yep, exactly my point/worry.
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.
Nah, it's no different from what we're already proposing with variable/sub/namespace partitioning--typeglobs are just an implementation choice. In particular, there are 2 obvious ways we could implement what we've got so far: a given namespace "object" manages 3 hashes--one to lookup variables, one for subs, and one for other namespaces. Or, a namespace could manage a single hash, in which you lookup a little structure which has one slot to hold a variable, one slot to hold a sub, and one to hold a namespace. The latter approach is basically a typeglob. You wouldn't necessarily expose that, but as an implementation detail it has some advantages, if there'd ever be a situation where you wanted to (say) look for "foo" by retrieving the variable if there is one, else a sub if there isn't a variable, else a namespace (advantage because there'd only be one hash lookup). Whether you've got 3 conceptual sections or 5, you'd have the same sorts of implementation choices.
In particular, a nice approach would be to allow a given namespace object to decide on its semantics based on the context (language probably) in which it was created--so a namespace created in Perl code might have 3 or 5 sections, and one created in another language might have only 1. If the namespace lookup API (ie, how you do a lookup once you've got hold of a particular namespace object) had a signature such as, lookup(namespace object, name of thing, type indicator), then the namespace could decide what it wants to do if it doesn't have a section for that "type" of thing--it could return null, fall back to a different type, signal an error, whatever.
Also, don't forget Perl5 (for Ponie)--it's never been characterized as having the sigil as part of the variable name. (At least, judging by the Camel.)
(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.
Yeah, but as I said before, I'm less worried that there will be _some_ such cases, and more bothered that even if you try to coordinate, you can't create in Perl a variable which is legal in Python, or create one in Python which is legal in Perl. It's bad if our approach leaves zero overlap. (And if we do have zero "natural" overlap between Perl6 and Python, I'd probably argue that we should partition Python and Ruby apart, so that introspective lookups would have to specify a language. But that's all just awkward.)
('specially since I'm not sure my mail client will let me either...)
Ha, yep, I assume you meant: $éååä. (Your client specified the wrong encoding [ISO-8859-1 instead of Shift_JIS] in the MIME headers--but I know mine won't. :)
Besides, Python's OO and we all know global variables are evil things one doesn't use in OO code, right? :)
True, they're evil-ish, OO or not, but more benign in short scripts, which P/P/R tend to favor. (And of course globals inside namespaces are still globals, but better behaved since they have fancier::looking::names.)
(And one legitimate use of inside-a-package-but-still-global variables is for constants relevant to the package. Java does that a lot. As a made-up example, stuff like java.lang.math.PI)
For me, I want to be able to load some compiled bytecode module, and not care what language it was written in.Alas, there will always be problems. We can make interoperability *possible*, but that doesn't mean we can make it *easy*.
Yes, but we should *try* to make it easy and elegant, and not resign ourselves too easily to giving up on it.
(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)...
Eh. Maybe, but that assumes a widespread usage of cross-module globals. That's pretty rare.
Ha, but that all argues for *not* implementing features like tied-hierarchical-overlayed-lexical namespaces, which will only encourage the use of globals....
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.
I guess. I'm still waiting for someone to step up with an example that doesn't smack of what beginning Perl users do when they discover you can access global variables by name, and they abuse the global namespace by doing ${$key} instead of $hash{$key} to store stuff. And since I've never heard of a language with tied namespaces, I wonder how they've lived with the suffering so far? :)
JEff
