> How, exactly, is taking two strings, making a third string that's big > enough to contain both, and copying the contents of those two strings > into the third one like taking two numbers, doing a binary OR with > carry, and storing the result in a third number?
Firstly, you have made an assumption that the addition here is equivalent to OR and carry, which may be correct for certain representations of integral datatypes, but certainly isn't for any kind of floating point arithmetic that I know of. Secondly, you missed the point that I was making. The current add opcodes defined in parrot are the following: add (in PMC, in PMC, in PMC) add(in PMC, in INT) add(in PMC, in NUM) add(in PMC, in PMC) add(in PMC, in PMC, in INT) add(in PMC, in PMC, in NUM) add(inout INT, in INT) add(inout NUM, in INT) add(inout NUM, in NUM) add(out INT, in INT, in INT) add(out NUM, in NUM, in INT) add(out NUM, in NUM, in NUM) I was simply asking why there wasn't an add(out STR, in STR, in STR) which seems reasonable. This is not a question of operator overloading, but rather semantics - that's all. > Some languages overload addition to do both. Other languages don't; in > fact, a Perl add and a Perl concat (to take one example) behave very > differently from one another. Ahh yes, but this includes implicit type conversion, which is not what you want to do in Parrot (if I am to understand Dan correctly) DanS> Right now it's flat-out disallowed in parrot, and I'm also DanS> comfortable with that. (Plan on keeping it that way, honestly) > Generally speaking, it's better for compilers to do a bit of extra work > to figure out the argument types involved than it is for them to throw > away information they already have. (Besides, it's not that big a deal > with PMCs--a PythonString can put the same code in its concat_*() and > add_*() vtable entries.) Agreed, though in this case it's the opposite. The compiler doesn't need to do any extra work because it knows exactly what argument types it has. Thanks, Matt
