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.
> And even if we did do something like this, we'd be penalizing calls to
> add that *do* have correct arguments.
Define "correct".
If add only has assign semantics, then any language which wants set
semantics must first allocate a new pmc, then add with that as the
target.
If add were to only have set semantics, then any language which wants
assign semantics must first add, then assign (and then, I suppose, null
out the pmc which add created for it's target so it can be GC'd.)
(Note that if add were to have set semantics, it wouldn't be parrot's
decision about what type of pmc the target should have; that decision
would belong to the add vtable entry of the first of the two things
being added together.)
Clearly, having *only* an add with set semantics would be wrong, since
there'd be no way to avoid having the extra pmc created. (Not to
mention, even if we want to assign the result into one of the pmcs being
added together, our result still has to go into a register other than
one of them; this might require spilling registers first.)
However, having *only* an add with assign semantics isn't perfect
either, since to simulate set semantics, we have to allocate a target
pmc beforehand, which means must decide what type the new pmc should be
-- either we allocate a PerlUndef (or some other fixed type, which
regardless of what it is, might just possibly be the *wrong* type).
This puts the burden of the decision about what type the target should
be allocated as completely on the host language's shoulders, and doesn't
let the pmc's involved decide. Well, I suppose one could do:
result_type_for_add $I0, $P1, $P2
$P0 = new $I0
$P0 = $P1 + $P2
, but this is rather clumsy. I'd rather have two versions of add, one
with set/create semantics and the other with assign/mutate semantics.
--
$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;}
