intertwingly

While exploring Python on Parrot, I was curious to see how Parrot handled Dealing with Diversity.  Running pie-thon against print '1' + '2' produced the following PIR code:

         $P1 = new PerlInt
         $P1 = "1"
         $P3 = new PerlInt
         $P3 = "2"
         $P2 = new PerlInt               # BINARY_ADD
         $P2 = $P1 + $P3
         print_item $P2          # PRINT_ITEM
         print_newline           # PRINT_NEWLINE

Running Parrot without any options against that code produces 3 as the result.  You might think that that is because "1" and "2" are coerced into integers before the addition, but in fact the reverse is true.  Assigning a string to a PerlInt results in a morphing of the target:

     void set_string_native (STRING* value) {
         DYNSELF.morph(enum_class_PerlString);
         DYNSELF.set_string_native(value);
     }

It turns out that the addition itself will evaluate the strings prior to doing the addition — or will, but only if the --python option is not specified.  If it is specified, string addition is defined as concatenation.

Varying runtime behavior in this manner seems like an extraordinary bad idea.  A better solution would be a separate PythonString class.

The morphing behavior of assignment isn't consistent either.  If you define a ResizablePMCArray, assigning an integer to it seems to be the way you set the length.

In any case, here is a patch to Pirate to take advantage of this behavior.  This caused the range test to fail due to a latent bug in Pirate that was masked by another set of unexpected behavior — in this case how negative fractional numbers are rounded to integers also seems to depend indirectly on whether Parrot is run in --python mode or not.

Finally, running in --python mode changes the behavior of generators in Pirate.  Mind you, it doesn't make them work just yet, just behave differently.