On Wed, 14 Aug 2002, David M. Lloyd wrote:
> > The problem was that the math vtable methods were giving up if the
> > other side of the operator wasn't an int or a num. So the current
> > version of PerlArray would make $x undef. I'm not sure getting the
> > other thing's int value (as opposed to its num value) is the right
> > thing, but it seems like a reasonable guess.
>
> Something tells me this approach isn't quite right but I don't know
> what. It seems odd that, for instance, @a decides what context to take
> @b in. How do we say 'scalar context' in Parrot? What if @b is "Blah"
> in scalar context? Does it return 0 then?
I thought about this more. Here's a brain dump:
Here's how I'd expect these expressions to be executed internally, in
gross pseudocode, ignoring for the moment the multimethod vaporware:
$r = $a + $b; # $a->add($a, $b, $r)
$r = @a + $b; # $t = @a->get_pmc(@a); $t->add($t, $b, $r)
$r = $a + @b; # $t = @b->get_pmc(@b); $t->add($a, $t, $r)
$r = @a + @b; # $t = @a->get_pmc(@a); $u = @b->get_pmc(@b); $t->add($t,
$u, $r);
@r = $a ^+ $b; # Something that makes one-elment arrays and
# uses add method on array object? Or perhaps
# error
@r = @a ^+ $b; # Does this distribute? If so,
# @a->add(@a, $b, @r) else see above
@r = $a ^+ @b; # See above
@r = @a ^+ @b; # @a->add(@a, @b, @r), easy
- D
<[EMAIL PROTECTED]>
