On Sep 28, 2004, at 12:28 PM, Chip Salzenberg wrote:
According to Dan Sugalski:At 11:58 AM -0700 9/28/04, Jeff Clites wrote:On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:top-level namespace (say this is namespace #1): { variables => { Foo => <PerlScalar PMC (or whatever)> }, namespaces => { Foo => <PerlNamespace PMC, call namespace #2> } }
I think I get it. You're replacing sigil characters and associated name mangling, turning it into explicit named categories, thus avoiding lots of anticipated string tricks.
Yep, exactly.
And unfortunately dies a horrible death for languages that don't categorize the same way as perl. :(
The horrible death you fear is unavoidable. The variable categories are an impedance mismatch that namespaces can't paper over. Name spaces have different dimensionality, if you will, in different languages. We can't *fix* that without changing the languages.
You said on IRC that the Perl/Python gap would have to be bridged with one-shot namespace connection, something like Exporter. (Perl "$a::b" => Python 'a.b', Perl "@a::c" => Python 'a.c', etc.) So the import process could use Jeff-style categories to get some handle on what's being imported. e.g.:
parrot_alias(a, 'b', # dest: Python is unified, no need for a category here
a, 'b', 'scalar') # src: Perl is not unified, so source category is required
parrot_alias(a, 'c',
a, 'c', 'array') # here's a different category, to get '@c'
or some such. Yes it's ugly. But if we can't fix a ditch, the least we can do is put a big friendly warning sign on it.
Exactly. If Python want to alias to a Perl variable, it's going to have to specify the category one way or another. Doing string-fiddling by putting a sigil on the front of the string is one way, but just specifying a category explicitly is another. The latter is a much more natural thing to do, in regard to languages which don't themselves have sigils. And the string-fiddling seems like more of a hack--why try to shove the category and name information together, into a single string, rather than leaving them separate?
I'm not even suggesting an implementation here really; it's just, "namespaces need to handle multiple syntactic categories", and we need to have API to reflect this. And you hit the nail on the head that these are *syntactic* categories. These syntactic categories should always be known at compile-time (which is what makes them syntactic categories); for languages with sigils, its easy, and for languages without them (most), the grammar of the language defines it.
And in terms of adaptors, I think that aliasing from Perl to Python is going to end up aliasing '[EMAIL PROTECTED]', and never '@c' really (since Python always holds references--really aliasing to '@c' would imply that assignment within Python would copy); conversely, going from Python to Perl would always end up as a scalar on the Perl side, since everything from Python would look like a reference to Perl. (At least, this seems like the most natural approach.)
JEff
