On Sun, 17 Aug 2003, 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.
Sure, you can do that in python: >>> class Add: ... def __add__(self, other): ... print "we don't need no steenkin", other ... >>> x = Add() >>> x + 1 we don't need no steenkin 1 But if you know the types of the objects, it makes sense to do the change Benjamin is talking about. So this probably ought to be done at the AST code generation level. Leo sent me a patch that does some basic type inference in pirate and figures out when not to generate the extra PerlUndef. It's in the method binaryExpression. (It's just not used yet because at the time it wasn't compatible with the way I was handling expressions; I've been trying to get my code to work his way, but didn't go back and check whether it worked yet.) Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --------------------------------------
