On Sep 29, 2004, at 2:53 AM, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:Okay, so we've got two points of dispute:
1) Jeff doesn't think the sigil should be part of the variable name
Which isn't practicable. We can't strip off the sigil for perl5. It's part of the variable name, $foo and @foo are different items.
Those statements don't follow from one another. :)
First off, Perl5 doesn't describe itself that way. The Camel states, "Note that we can use the same name for $days, @days, and %days without Perl getting confused." I'm asserting that it works perfectly well (and seems to have been the original intent) to say that Perl allows for a scalar, a hash, and an array all named "foo", and the grammar always makes it clear which one you mean (mostly, via sigils).
So it's true that $foo and @foo are different items, but that can be stated as, "the scalar 'foo' and the array 'foo' are different items, with the same names". (Just like there can be both a person named "April" and a month named "April" in English.)
Here are some further demonstrations that the seeming intent of Perl5 is not to treat the sigil as actually part of the name, but as a feature of the grammar which indicates the syntactic category of the name:
$hello and ${hello} are the same thing, but $hel{lo} is not -- the name can separate from the sigil
$array[1] refers to @array, not $array -- the sigil changes depending on context, even for a given item
Secondly, Perl just clouds the issue, since it _could_ work either way. For other languages, you have distinct syntactic categories, but without the name decoration. For example, in Common Lisp, this:
(foo foo)
means, "call the function foo, and pass the variable foo as an argument". So if the function "foo" doubles numbers, and the variable "foo" is set to 11, then the above evaluates to 22.
The reason I'm taking this as important, despite Common Lisp's not being a "target" language for Parrot, is that it's pointing out that namespaces across languages have the concept of dealing with multiple syntactic categories, though the number of such categories varies between languages. Ruby and Python are simple--they have unified namespaces, or so it seems--and Perl has a syntax which allows us to pretend that it has a unified namespace, although I think that's stretching the truth. (And, I think there's still an issue with namespace names and sub names, since they don't have sigils in the grammar--at least not as normally written.) But other languages aren't so simple, and if we oversimplify our treatment of namespaces, then we end up with something less elegant and less flexible that we could have.
If you want to use a perl5 module from Python which has both $foo and @foo exported, we can just pitch a fit.
We should be able to handle accessing either, if Python provides a syntax for doing so.
And: we can't attach hints to the namespace lookup because you just don't know, if Python wants the scalar "foo" or the array "foo". There is exactly one "foo" object that Python can use, that's it.
That's not accurate, and it's not a hint, it's a demand--the programmer should know exactly which one he wants (which is especially true if you are trying to think of the sigil as part of the name). Possible syntaxes within Python:
a = lookupPerlScalar("foo");
b = lookupPerlSub("foo");
c = lookupPerlArray("foo");or its:
a = lookupFromPerl("scalar", "foo");or it's:
a = lookupInParrotNamespace("Perl", "scalar", "foo");Since Python deals in references only, assignment syntax could work just fine for this, but if someone wanted a more aliasing-like syntax, it could work like what Chip suggested in another thread:
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.
I've lost hope for transparent aliasing, but it would work partially so say, "imports from Perl to Python can automatically alias scalars to Python variables of the same name, but arrays and hashes you have to pull in manually, and alias to an explicitly-specified name on the Python side".
It will never "just work" for all things, since this is a valid identifier in Common Lisp: *foo-foo*
So to exploit the full power of Parrot, languages will need to have syntaxes/functionality/API to access "foreign" namespaces, but things could be made transparent for at least a subset of variables. (And as an example, not _all_ identifiers in Common Lisp are so exotic.)
Python allows only bare names in the import statement:
from a import foo [ as a_foo ]
but not:
from a import "@foo" [ as a_foo ]
This seems to make things worse for treating the sigil as part of the name, no? But anyway, I'd expect languages to need new syntaxes (or use other introspection API) in order to fully access the namespaces "born" in other languages.
2) Both Jeff and Jonathan have pointed out that languages we care about *do* have a combined function/varname store. (Though class names/namespaces seem to be separate)
No. Python just has names. Assigning something to a name binds that thingy to that name.
I think that's what Dan means--there aren't separate syntactic categories (in contrast to other languages, such as Perl).
The tricky part of Python "objects" is now to create real Parrot objects
out of it, which might be impossible for the general case. But for
normal cases the method call translates to a real Parrot method call,
with a method "foo" in namespace "A". Such methods would be usable from
Perl6 or other languages that use Parrot's object model.
I think we have issues going from Perl to Python as well, in other cases. Things such as arrays/hashes/strings should come across as references--so I'd say that in Python you access [EMAIL PROTECTED] rather than @foo directly, because assignment in Python doesn't copy. For strings this works too (Python sees a reference to the Perl string). But for a Perl scalar holding a reference, it would seem natural for this to present to Python as that reference directly--not as as reference to that reference. But it's not clear what's best to do here.
JEff
