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