Luke Palmer wrote: > > Benjamin Goldberg writes: > > Hmm... I just thought of something. Since 'set' semantics can be > > easily simulated when we have only ops for 'assign' semantics, maybe > > imcc itself could do this for us. > > > > That is, by default, > > $P0 = $P1 + $P2 > > will be translated by imcc into > > add $P0, $P1, $P2 > > but, if some command is given to imcc, then it will be translated into > > new $P0, .PerlUndef > > add $P0, $P1, $P2 > > Or, instead of PerlUndef, the command to change to set semantics would > > indicate what to put into $P0 prior to using it as the target of an > > add (so we can initialize $P0 with any of PerlInt, PerlNum, BigInt, > > BigFloat, BigRat, ContinuedFraction, etc.) > > Hmm, I wonder whether this is the right approach. What about operator > overloading? Let's say Python overloads + (can it do that?) and passes > that variable to Perl. If Perl creates a .PerlUndef and assigns to it, > you lose the overloaded semantics.
Eh? I would think that if Python overloads +, then that means it's creating a PMC with a vtable->add different from a "normal" addition operation. If we "assign" that pmc to a pmc which was PerlUndef, then the vtable (pointer) gets assigned, too. Doesn't it? Unless you mean, "let's say Python makes a pmc with an unusual vtable, and overloads vtable->add in such a way that it expects it's target to be a <something> pmc, but instead, we pass in a PerlUndef." If vtable->add doesn't bother checking that the target isn't the right type, then it's broken. It should either throw an exception if it's not what's wanted, or else mutate/promote that PerlUndef to the right type. > I don't know... I think using vtable multimethods would be the best way > to go wrt these things. Umm, I didn't think that I was suggesting something else -- I was suggesting merely that imcc can be told to produce to pretend that +, -, and other mathematical operations have "set" semantics, and have it produce parrot ops to support that pretense. Within parrot, the "add" op would still be the same as it always has been (merely calling the vtable->add method). And I'm not suggesting that the vtables be changed. The only difference would be, *if* that command had been given to imcc, then any "add" op in the bytecode, which had originally been spelled as "+" in the pir code, would be preceded by a "new" op (put there by imcc). -- $a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca );{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED] ]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}