At 10:26 PM 9/27/2001 +0200, Samuele Pedroni wrote:
>[Dan Sugalski]
> > Yup. Dispatch will look like:
> >
> > result = pmc1->vtable[ADD + pmc2->vtable[TYPE](pmc2, NUM)](pmc1, pmc2);
> >
>
>Is that the way the add opcode for PMC is defined I imagine.
>And in this form it cost you always two calls.
Yeah, you're right. For some reason I've been assuming the vtable must be a
pure function pointer table. No reason not to make it a struct with some
constant stuff up at the beginning. Makes more sense, thinking about it.
>My understanding is that, for perl, PMCs
>would be for example of the generic type scalar and then have
>some concrete subtype (float or integer) and basically
>float and integer will share the scalar vtable.
>PMC at least for perl seem to be cells holding a value and a vtable
>and the value can change through assignment and the vtable is
>a bit more stable. Not object carrying a very concrete type.
>Is that right?
Sort of. The vtable is about as changeable as the value, since types can
have multiple vtables they choose from. For example, with this:
my $foo = 1;
$foo is a plain scalar, with a value of one. It gets the "plain scalar
that's an integer" vtable. If I later do:
print $foo;
and need a stringified version of the integer in $foo, the "plain scalar
that's an integer" first generates a string value, then morphs itself into
a scalar holding an integer and a string, and resets its vtable to point to
the "plain scalar that's an integer and a string" table. Still, as far as
Parrot is concerned, a variable of type Scalar, but now one with a few
different variants of its value and a vtable that has the most efficient
set of functions to deal with that data.
>With object carrying a concrete type:
>
> result = pmc1->vtable[ADD + pmc2->vtable[FAST_TYPE]](pmc1, pmc2)
>
>would possibly work but would not work for perl.
Don't worry, it will. Might get a little complex, but it'll work.
>I don't see how this model can accomadate the semantics of
>multiple languages ... at least not all at the same time and without
>tweaking. But was it designed with that in mind?
If you think about things in "The Parrot Way" (which is *not* The Perl
Way") it works out remarkably well. (OK, I think it will--we'll see once we
have PMC code working to play with) The interpreter requires a well-defined
set of common functions to be available that's large enough to permit fancy
optimizations if you want, and beyond that considers how things work to be
none of its concern.
Let me see about putting together some technical overview docs on the
variable scheme. I realize things are a bit spotty now, as half the
design's still not on paper yet. (Which is in some ways good, since I've
already changed a bunch of stuff directly because of the input from Python
folks--you think about things in different ways, which leads to different
problems and solutions. Which is cool)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
