Matt Greenwood wrote: > 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.
True enough, but I think I got my point across--concatenation is a fundamentally different operation from addition.
> Secondly, you missed the point that I was making. The current add > opcodes defined in parrot are the following: > (various combinations of PMC, INT, and 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.
I suppose that depends on what you want it to do. If you want it to convert $2 and $3 to integers, add them, convert the result to a string, and put it in $1, then the answer is "that's not a common enough operation to warrant adding the extra opcodes"--especially since the I/S/N registers aren't supposed to be used for anything but optimizations.
If you want it to concatenate $2 and $3 and insert the result into $1, and remove the "concat" opcode altogether...well, the answer stems from the existence of add(in PMC, in PMC, in PMC). What should that do--integer addition, or string concatenation? Remember, some of our languages don't overload add for strings. We need a separate concat(in PMC, in PMC, in PMC), so we might as well have concat(out STR, in STR, in STR) too.
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
