At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote:
>At 05:59 PM 11/30/00 +0000, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>> > (Moved over to -internals, since it's not really a parser API thing)
>> >
>> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>> > >Presumably. But why are you then still talking about "the IV slot in
>> > >a scalar"...? I'm slow today. Show me how
>> > >
>> > > $a = 1.2; $b = 3; $c = $a + $b;
>> > >
>> > >is going to work, what kind of opcodes do you see being used?
>> > >(for the purposes of this exercise, you may not assume the optimizer
>> > > doing $c = (1.2+3) behind the curtains :-)
>>
>>$a=1; $b =3; $c = $a + $b
>
>No, that's naughty--it's much more interesting if the scalars are
>different types.
OK, how would this sequence convert to opcodes?
$a=1.2; $b=5; $c = ($a.$b)*4;
Something like (using a load/store paradigm for the opcodes, for variety):
set num 1.2, r1 ;; $a = 1.2
store r1, $a
set int 5, r2 ;; $b = 5
store r2, $b
load $a, r1 ;; ($a.$b)
load $b, r2
append r1, r2, r3
mul r3, int 4, r4 ;; $c = ($a.$b)*4
store r4, $c
This is before obvious optimization (the loads are completely unnecessary,
but are here as an example)
The append would do something like r1->vtable->append[int](r2), as per your
last example, and would be responsible for coercing r2 to a string. mul
would do something like r3->vtable->mul[int](int2P6Scaler(4)), and the
mul[int] associated with strings would do the necessary conversions.
What I'm curious about is the following sequence:
use MyRomanNumerals;
$a = MyType->new(4);
print $a; # should print "IV"
$b = 4;
print $a + $b; # should print "VIII", maybe...
print $b + $a; # should print "8", maybe...
The execution of the two additions should be, based on what was said
before, something like:
a->vtable->add[typeof b](b);
b->vtable->add[typeof a](a);
How does b->vtable->add[] get an entry for MyRomanNumerals?
I seem to remember a suggestion made a long time ago that would have the
vtable include methods to convert to the "standard types", so that if the
calls were b->vtable->add(b,a) (and both operands had to be passed in; this
is C we're talking about, not C++ or perl. OO has to be done manually),
then the add routine would do a->vtable->fetchint(a) to get the appropriate
value. Or something like that. Have I confused something?
>Yup. What add does is based on the types of the two operands. In the more
>odd cases, I assume it's type stuff will be based on the left-hand
>operand, but I wouldn't bet the farm on that yet, as that's a Larry call.
That's what I assumed above, but who knows?
>> > But that probably doesn't help much. Let me throw together something more
>> > detailed and we'll see where we go from there.
>>
>>Hopefully it will cover the above case too.
>
>What, the "what if one of the operands is really bizarre" case?
And with Perl6, I thought we were planning allowing some really bizarre
cases? Has Larry indicated at all what his thoughts about fast powerful
TIED variables were?
> Dan
