Andrew Whitworth wrote:
On Sun, Jun 7, 2009 at 8:07 PM, Vasily Chekalkin<[email protected]> wrote:
Few days ago I created branch for implementing mathematical ops in term of
i_ops. E.g. "c = add a, b" implemented as "c = a; c+= b". No test failures
(actually I fixed some i_ops which was wrong before. E.g.
Integer.i_add(Complex) and so on), so I'm going to merge this branch to
trunk.
I seem to remember some months ago that the i_* operations were
supposed to be deprecated. I assume that this is no longer the case?
I don't think that we can get rid of i_ops because of performance reason.
If one set of arithmetic vtables is defined in terms of the other set,
doesn't that redundancy mean that we should be able to get rid of a
We can't get rid of 3-arg ops because official semantic of 3-args ops
for core pmcs can be different from HLLs. See last week #ps about C<dest>.
We can't implement automatic rewriting C<op> into C<i_op> without big
deprecation notice because they backing up MMD "op" invocation. E.g. "op
add" invokes VTABLE_add, which invokes MMD for non-core PMCs. And again,
C<dest> handling.
large number of vtable functions? I don't think we need to maintain
such a large set of VTABLEs, especially when the list is so massively
non-orthogonal.
+1. Why do we have VTABLE_pow, op pow(invar PMC...), but not VTABLE_exp
and op exp(invar PMC...)? Why do we have VTABLE_get_bignum but don't
VTABLE_get_biging? And so on.
--
Bacek
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
