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;}
