Matt Fowles <[EMAIL PROTECTED]> wrote:
> 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'd say: tied variables or references to variables:

  $r = \$a;
  $a = $a + 2;

If the add operation produced a new destination, the reference is lost.

> ... 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).

You can write it in both ways:

  temp = a + 2
  assign a, temp

or

  a = a + 2    # current sematics, a modified in place

or with lexicals/globals:

  a = find_lex "a"       # or a = global "a"
  a = a + 2

The final operation to assign the value to the perl var has IMHO always
to reuse the existing var.

> 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

We could do it that way too. OTOH it always needs two opcodes to
achieve the current effect of working with existing destination PMCs.

> and languages like python which have immutable scalars could always use

> $P0 = $P1 + $P2 # P0 created

As said, we can create either "__add" or "__n_add" depending on some
pragma or depending on the HLL.

> One concern that occurs to me is that this would cause more new PMC
> allocations.  But I am whether or not that is true.

The C<temp> above isn't needed, so yes.

>>    infix "__i_add", d, r

> I think this one is very necessary.

Yep

> Matt

leo

Reply via email to