Leo~
On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 5) infix method signature change:
>
> METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
> if (!dest)
> dest = pmc_new(INTERP, SELF->vtable->base_type);
> ...
> return dest;
> }
>
> If the destination PMC is passed in, it's used else a new PMC of an
> appropriate type is created.
I would actually appreciate a refresher on the original motivation
behind never autogenerating a LHS. I recall being told it has
something to do with tied data, but I was never clear on exactly how
that related. I would think that tied data would only require
VTABLE_assign method, and would not care how its RHS was created (via
an add or mul or whatever).
Thus I would argue for having most operators create their result (but
having a special assign that would call a VTABLE method) and forcing
languages with active data to go through a two step assignment
$P0 = $P1 + $P2 # P0 created
$P3 <- $P0 # P3 gets to run its tied code
and languages like python which have immutable scalars could always use
$P0 = $P1 + $P2 # P0 created
One concern that occurs to me is that this would cause more new PMC
allocations. But I am whether or not that is true.
> 7) separate inplace methods
>
> Opcodes like:
>
> d += r # add d, r
>
> are currently using the normal add method with the destination set to
> SELF. This is suboptimal, especially, when the destination PMC is
> morphed to a different type (e.g. due to bigint promotion) which
> destroys the value of SELF.
>
> It's just cleaner to have distinct inplace methods, it's very likely
> also needed anyway, as method overloading would not work if the inplace
> operations are the same.
>
> Therefore we have:
>
> infix "__i_add", d, r
>
> and in *.pmc
>
> METHOD void i_add( [INTERP, SELF, ] PMC* r) {...}
>
I think this one is very necessary.
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
