> +=item B<cmod>(out PMC, in INT, in INT)
I'm not sure if this is a good idea. We currently don't have any such
kind of ops that takes 2 natural types and spits out a new PMC
BTW, the doc above has out PMC, the implementation is:
> +op cmod(in PMC, in INT, in INT) {
so that's b0rken anyway.
But implementing *one* such opcode (cmod) implies that we have it for
all math ops for symmetry reasons.
A further note: while its safe to add opcodes w/o updating ops.num, the
next adding of unregistered ops might break the ops numbering (and
existing PBCs), so its not really recommended ;)
leo
Yeah, good point.
>BTW, the doc above has out PMC, the implementation is:
>
>> +op cmod(in PMC, in INT, in INT) {
>
>so that's b0rken anyway.
D'oh! That's what I get for doing a half-hack job. Dammit. I'll go
fix that. Well, OK, I'll go yank 'em, as this is a very good point:
>But implementing *one* such opcode (cmod) implies that we have it for
>all math ops for symmetry reasons.
>
>A further note: while its safe to add opcodes w/o updating ops.num, the
>next adding of unregistered ops might break the ops numbering (and
>existing PBCs), so its not really recommended ;)
I'm OK with not numbering officially straight off, at least until
things get hashed out a bit. In this case it's especially wise, as
the extra mod/cmod ops are going to get yanked. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> D'oh! That's what I get for doing a half-hack job. Dammit. I'll go
> fix that. Well, OK, I'll go yank 'em, as this is a very good point:
These c?mod opcodes are history. I've deleted them
ops.num is updated.
leo