Dan Sugalski wrote:
> At 01:50 PM 2/6/2001 -0200, Branden wrote:
> >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.
Sorry 'bout that, it was only to illustrate having the PMC's in C without
having to mention the compiler, or anything else...
> 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.
>
I actually don't see anything related to foo here, besides the last line of
it, which is actually the same as the set_string entry of the same vtable.
And if we replace that line for the correspondent set_string operation, I
don't see the need to have add in a vtable, because I cannot understand how
it could be implemented differently for another variable aside from foo.
And the line that sums the two values doesn't take into account the fact
that baz has + overloaded to make some test if the values are strings, to
concatenate instead of sum. How would foo's vtable have to deal with that?
> 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.
>
But the more one vtable has to deal with other vtables, the less code
re-using and extensibility we have.
For example, if we replace + for - in the expression, as
$foo{bar} = $baz - $xyzzy[42];
that would be implemented as
: struct key keys[] = {
: { KEY_TYPE_HASH, (struct hash_key *) "bar" },
: { KEY_NONE, NULL }, // scalar
: { KEY_TYPE_ARRAY, (IV) 42 },
: { 0, 0 } };
:
: foo->vtable->subtract(foo, baz, xyz, keys);
and then subtract would have to 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));
Why would we make subtract deal with getting the int's from baz, and xyzzy,
and storing the data in the database, if it could only make the subtraction?
At least it what its name says it's meant to do...
> >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.
>
What's exactly a op dispatch? I _really_ don't know that. Please tell me so
that I can answer this...
> 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 know that (althought I don't have the exact definition of opcode yet). I
wrote C code only to illustrate my point.
If a opcode is what I'm thinking, in the fact that the interpreter executes
a opcode kind of atomically, like a machine instruction in assembly, then I
would like to say that the entries you are proposing to the vtables are
probably much better as opcodes than mine. But I'm actually not saying that
one vtable function call should be a opcode. I mean, an `add' instruction
could be built above that that would do all that at once, and that could be
the opcode...
I actually don't see a reason why the vtable entries should be the opcodes.
Is there?
> > > --
> > > 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...
>
But I like it! ;-)
Thanks,
- Branden
