At 01:50 PM 2/6/2001 -0200, Branden wrote:
>Simon Cozens wrote:
> > On Tue, Feb 06, 2001 at 11:30:12AM -0200, Branden wrote:
> > > I actually have some more on it, but I'm saving it for the next
>postings.
> > > I'll wait for your opinions first. I really hope to see critics about
>this.
> >
> > I don't understand what you think this gives us that the PDD doesn't.
There are a few conceptual issues here. I can't speak for yours, but I'll
correct the bits I can.
>To explain the difference, I'll show how the Perl statement
> $foo{bar} = $baz + $xyzzy[42];
>would be traduced in both approaches.\
>In the approach using the vtables I propose, it would be:
>
>
> // get the PMC's that correspond to each variable...
> HVAR *foo = get_hvar("foo");
> SVAR *baz = get_svar("baz");
> AVAR *xyz = get_avar("xyzzy");
This likely won't be done this way. Variables looked up by name (package
and named lexicals (if we even let you look up lexicals by name)) will be
handled like this (though we'll probably do a bunch of optimization) but
lexicals will not be. The compiler will pre-compute what it needs so we'll
have a PMC already, or find them with an array lookup in the appropriate
place in the lexical stack.
> // temporary...
> SVAL *foo_val = new_sval_temp();
> SVAL *baz_val = new_sval_temp();
> SVAL *xyz_val = new_sval_temp();
We're going to have a bunch of temps handy so this won't need to be done.
> // this ones actually come from compiler...
> SVAL *foo_key = new_sval_pv("bar");
> SVAL *xyz_idx = new_sval_iv(42);
Yep--constants will be precomputed.
> // fetch $bar and $xyzzy[42] values
> baz->vtable->FETCH(baz_val, baz);
> xyz->vtable->FETCH(xyz_val, xyz, xyz_idx);
> // add them into a temporary
> baz_val->vtable->ADD(foo_val, baz_val, xyz_val);
> // probably xyz_val->vtable->INTEGER(xyz_val)
> // and/or xyz_val->vtable->NUMBER(xyz_val) would
> // get called by the ADD implementation, to
> // inspect the right operand's value.
> // store this value on $foo{bar}
> foo->vtable->STORE(foo, foo_key, foo_val);
>
>
>Using the vtable approach proposed in the PDD:
>
>
> // get the PMC's that correspond to each variable...
> struct key keys[] = {
> { KEY_TYPE_HASH, (struct hash_key *) "bar" },
> { KEY_NONE, NULL }, // scalar
> { KEY_TYPE_ARRAY, (IV) 42 },
> { 0, 0 } };
>
> foo->vtable->add(foo, baz, xyz, keys);
>
>
>Right? (Maybe I got it wrong, but for what I've read, that's it...).
I shipped out the code that's irrelevant (as the compiler will probably
also chop it out, 'specially if it's all accessing lexicals.
>Well, when %foo, $baz and @xyzzy are plain hashes, scalars and arrays, it's
>ok. But now suppose %foo is a hash tied to a database through DB_File or
>AnyDBM, @xyzzy is attached to a directory so that $xyzzy[42] would actually
>return the name of the 43rd file in that directory, and the string stored in
>the $baz variable has overloaded + so that it will check if the other
>argument is a string or a number, and concatenate in case it's a string and
>sum only if both are numbers. How would foo->vtable->add(foo, baz, xyz,
>keys) deal with that? As it is %foo's vtable, I agree that it should know
>about %foo being tied to a DBM, but how would it know anything about the
>others?
Well, the code *inside* foo's add would do:
IV lside = baz->vtable->get_int[NATIVE](baz, key+1);
IV rside = xyzzy->vtable->get_int[NATIVE](xyzzy, key+2);
IV sum = lside + rside;
db_store(foo->data->db_handle, KEYSTRING(key[0]), IV_TO_UTF8(sum));
And yes, using the KEYSTRING and IV_TO_UTF8 macros to do the conversions is
a bit of a punt, but that's OK at this point.
There's nothing wrong with a vtable's function from using the vtable
functions of its arguments. It's actually a requirement if the arguments
aren't all of the same class.
>In the approach I'm proposing, xyz->vtable->FETCH(xyz_val, xyz, xyz_idx)
>would ask for the element indexed 42 of the array. As the vtable used is the
>one of the array itself, it knows it should fetch it from the directory
>listing, and does it. In baz_val->vtable->ADD(foo_val, baz_val, xyz_val),
>the ADD method is called from the $baz vtable, so it knows about $baz being
>overloaded. (Of course overloading this way only applies to the left
>operand, I don't know if there's a workaround for this). The ADD method gets
>the right operand by calling STRING/INT/NUMBER on the last argument. And
>foo->vtable->STORE(foo, foo_key, foo_val) is responsible for storing the
>value on %foo, using foo_key as the key. STORE is in %foo's vtable, so it
>knows it should actually write the data in the DBM.
Nothing wrong with that, but there are more op dispatches that way. While
that's not a horrible thing, if we can avoid them that's better.
Don't forget we have an opcode machine here--we are *not* emitting C code
to be compiled. That means we're going to be storing temps in a register
file of some sort. (Or pushing them on a stack, or whatever) That means
that if we generate intermediaries that aren't PMCs then we need extra temp
space for them. Your way will mean an int, num, and string stack (or
register file, or whatever) in addition to a PMC stack/register
file/whatever. That's more stuff to track. (Which isn't to say we won't,
mind. We will if we have to)
>I really can't see how this would be implemented in the PDD proposed
>approach, unless foo->vtable->add(foo, baz, xyz, keys) makes the calls in
>the other vtables. And if it makes all these calls in the other vtables, I
>don't see the point, because every `add' function would have to explicitly
>do 2 fetches and 1 store, yet taking care of the keys, when it could
>actually only do the addition...
>
>Perhaps I didn't understood it quite well, but that's what I thought about
>it...
Looks like you hit it dead-on. I don't think you've got your head wrapped
around the execution being done by an opcode interpreter, though.
(Generally speaking this is a good thing, but since it's what we're doing
it's necessary)
> > --
> > For me, UNIX is a way of being. -Armando P. Stettner
> >
>
>For me too.
Just remember that it's not the only way to be...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
