On Mon, 2004-10-11 at 14:03, Sam Ruby wrote:
> Here's a script that will run in both Python and Perl. It simply will
> return different results.
>
> print "1" + "2" ,"\n",;
> print "45%s8" % "7" ,"\n",;
> print 45 / 7 ,"\n",;
> print ['a','b','c'] ,"\n",;
> print ['a'] + ['b'] ,"\n",;
> print 9 + None ,"\n",;
That last line fails under my python, but ignoring that:
example 1: I don't get the complexity here. Python's add is a special
case function that doesn't have much to do with the Parrot addition
operators except in that, in some cases, it calls them (and in other
cases, it calls ops like "join"). We have to distinguish the job of the
compiler writer from the job of the Parrot interpreter writer here, and
I don't think this is Parrot's concern.
example 2: This is just abusing the difference between "%" in Python and
in Perl. No shock there. Don't confuse syntax with semantics.
example 3: Python does integer math on integers, Perl does
floating-point. Again, not an issue.
I'll stop there. I think it's clear that there's two desires here. One I
think is reasonable, and one is (IMHO) not.
To want to be able to pass a PyString to a Perl function is fine.
To want to be able to pass a PyString to a Perl function and have it
mutate any code that uses it into Python semantics just doesn't make
sense to me.
The caller's semantics will drive how such things behave, and those
semantics will be imposed by the compiler in many cases, not Parrot.
If, for example, the caller turns:
a + b
into:
[...]
join result, a, b
[...]
then that's what happens, and if "a" happens to be a PerlString, too bad
that it doesn't think that "+" can mean concatenation.
If your compiler turns everything into an object, then the surprises
that develop from using variables that are alien to your object tree are
not, in fact, surprising.
Your concerns about hash behavior make more sense to me, and I do think
that hashing should be a core property of all PMCs. For those who don't
agree, go take a look at the mess that is C++-STL, and try this:
std::hash_map<std::string> myhash;
I love the STL in concept, but in practice it's full of gotchas like
this because the object tree is too disjoint because the foundation was
never set in such a way that the later pieces fit.
--
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs
