At 03:02 PM 11/30/00 -0500, Buddha Buck wrote:
>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)
That looks pretty much right. We're going to have to work out some sort of
perl assembly language standard, I think. A job for the bytecode definition
group. :)
Which makes me think we should have a bytecode assembler, too, but that's a
job for a different time.
>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.
Yup, more or less.
>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?
It falls into the "all others" catch-all category. How that behaves is up
in the air, but I'm thinking all types should have a way to force
themselves into generic bytes for string coercion, platform-native integer
for integer coercion, and platform-native float for num conversion. If data
is lost, well, there is a limit to what we can do for people automagically.
>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?
Nope.
>>> > 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
Not that I recall, but I've a memory like a steel sieve, so don't take it
as gospel.
At some point there is a limit to what we can do, and the programmer will
have to get explicit. I think that's a given. (Though I've been thinking
about things like an "ifactivevariable_branch" opcode, and have the
bytecode compiler generate two separate chunks of bytecode for some
operations, and decide which to take at runtime based on whether the
variables involved are active data or passive data)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
