On Wed, Aug 01, 2001 at 12:21:52PM +0300, Moshe Zadka wrote:
> On Wed, 1 Aug 2001 10:58:13 +0200, Thomas Wouters <thomas@xs4all.net> wrote:
>
> > He's disagreeing. It's not a PERL vs. PYTHON ADD at all; it's a "string
> > concatenation add" vs. "numerical add". Perl code using the string
> > concatenation operator (apparently, it's not going to be ".", which scares
> > me shitless: Perl6 gets a new string concat operator, but it isn't going to
> > be "+" ? If it is going to be '+', how does it flexitype ?) would use the
> > string-concat add opcode, and Perl code and Python code doing '+' would get
> > the normal BINARY_ADD. The string-to-int conversion in Perl's '+' would be
> > put into the 'Scalar' type.
> I think I've lost you.
> But if you're thinking about Perl compiled to something like
> PUSH "1"
> CONVERT_TO_INT
> PUSH "2"
> CONVERT_TO_INT
> BINARY_ADD
No, I'm not. I was, but I'm not.
Okay, Moshe, lets try this again. Imagine a Python object, "Scalar", that
behaves like a Perl $calar. We're not going to talk about merging the Perl
and Python VM here, just about a Python object that behaves somewhat like
a Perl scalar, and (for the sake of the discussion) just the string<->int
part of the flexitype.
The Scalar holds its value as a string, unless it's been stored as an int or
'modified' into an int. Pretend we have an operator "@" to explicitly
string-concatenate, exactly like Perl's ".". Now look at this code snippet:
one = Scalar("1")
two = Scalar("2")
three_num = one + two
three_s = one @ two
"one + two" would simply all BINARY_ADD, and the Scalar type's
tp_as_number->nb_add would convert its value internally to an int before
handling the operation. "one @ two" would call BINARY_CONCAT (or whatever),
which would call a different method to calculate the result. Effectively a
different operation.
But this isn't "perl add versus python add". "perl add" is just the same as
"python add" with a slightly different type, we just get a new opcode for
the "perl string concat" operator.
Like I (and Eric) said before, there's a lot to be done, and there's bound
to be a lot of issues (like how to get *both* scalars to convert their
value to a number before arithmatic, above, without resulting to something
like PyObject_AsInt() for all binary arithmatic) but those are most likely
not insurmountable.
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4