Benjamin Goldberg wrote:
> Brent Dax wrote:
> > TOGoS:
> > # When I say in IMCC:
> > #
> > # $P0 = $P1 + $P2
> > #
> > # , I expect it to create a new value and store it in
> > # $P0, not give me a segfault because I didn't say
> > #
> > # $P0 = new <figure out what the heck type
> > # $P0 is supposed to be based
> > # on the types of $P1 and $P2>
> > #
> > # first.
> >
> > Then your expectations are wrong.
> >
> > I think you may be losing sight of the fact that most users will *never*
> > interact with PASM or PIL directly. Most users will have a
> > parser/compiler/optimizer between them and PIL--one that was written,
> > tested and debugged by experts. The few people who work with raw
> > assembly or IL should know what they're doing. While I have no problem
> > with IMCC-time warnings about constructs like this ("Use of
> > uninitialized register $P0 in add"), I don't think we should coddle the
> > user at this level.
> >
> > Moreover, there really isn't any way to do what you want to do here.
> > There is no way for the add opcode to intuit what type should be put
> > into $P0.
>
> Noone is saying that the add opcode *should* try to intuit that -- he's
> trying to say that there should be two versions of the add opcode, one
> of which uses assign semantics, and the other of which uses set
> semantics.
>
> > That's ultimately the host language's decision, not Parrot's,
> > and the host language may have complicated rules to decide it.
>
> It would be the host language's decision about which opcode to use.
>
> I suppose that if one writes:
> $P0 = $P1 + $P2
> , then it might be parrot's (imcc's) decision about which opcode to
> compile it to... but of course, the host language can avoid that
> ambiguity by writing it out explicitly, as "add_set( $P0, $P1, $P2 )" or
> "add_assign( $P0, $P1, $P2 )". Or perhaps, require some pragma
> indicating to imcc that all $Px = $Py + $Pz should use the add or assign
> versions of the ops.
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.)
--
$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;}
