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 Then it's only a matter of time before the Perl guys find out it's hella slow and optimize it to: PUSH "1" PUSH "2" CONVERT_TO_INT_TOP_2 BINARY_ADD And then to PUSH "1" PUSH "2" CONVERT_TO_INT_TOP_2_AND_BINARY_ADD And then a simple #define CONVERT_TO_INT_TOP_2_AND_BINARY_ADD PERL_ADD Would finish the 2*PI circle to land exactly where we started with. ;-) -- gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6 Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE Learn Python! http://www.ibiblio.org/obp/thinkCSpy
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