pmc_i_ops branch.
Vasily Chekalkin
bacek at bacek.com
Mon Jun 8 02:18:11 UTC 2009
Andrew Whitworth wrote:
> On Sun, Jun 7, 2009 at 8:07 PM, Vasily Chekalkin<bacek at bacek.com> 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
More information about the parrot-dev
mailing list