At 12:31 PM 20/04/2001 -0500, Jarkko Hietaniemi wrote:
>In general the extensibility (and the size) of the vtable worries me.
>Should we have multilevel vtables? Arithmetic subvtable, bitop
>subvtable, et cetera?
Actually, I don't think that's necessary.
First of all, changing one subvtable independent of other vtables during
runtime would be kind of meaningless, even more because the vtable should
be the only one way that knows the internal structure of the data field.
Having multiple subvtables that must agree on the internal structure of the
data wouldn't be a good idea.
And, if the subvtables apply to the same kind of data (they share the same
data structure), they can be combined statically. For example, suppose I
implement sval_vt1 and sval_vt2 vtables with methods vt1_plus, vt1_minus,
vt1_bitand, vt1_bitor, ... and vt2_plus, vt2_minus, vt2_bitand, vt2_bitor,
.... I could then define a sval_vt1and2 with entries vt1_plus, vt1_minus,
vt2_bitand, vt2_bitor, and any other combination.
Thus the possibility to combine two or more vtables into one could be done
without adding the extra cost of another lookup level.
> > // numeric operations
>I would call this 'arithmetic', 'numeric' is a bit too general a term.
> > void (*PLUS) (SVAL *result, SVAL *this, SVAL *value);
>Exponentiation? Negation?
>
>Instead of modulus have a single function returning both the
>integer part and the modulus?
Good points!
That's why it's good to design a language on a list. We always forget about
the details...
>What is someone wants to define matrices and have both cross product
>and dot product?
Actually, operations like PLUS and TIMES don't directly mean logical
operations, but actually *syntatical* operations. For example, TIMES is the
operation that is supposed to be called when the user uses the '*' operator
in the Perl code. So the handling of two kinds of products would actually
depend on the kinds of *syntatic* operators used.
For example, I would define a matrix class (that would be stored in a
scalar rather than array variable), that would use * for its dot product
and x for its cross product, so that if $a and $b hold matrix values, `$a *
$b' is the dot product and `$a x $b' is the cross product. Then, I would
have to define TIMES to do the dot product, and REPEAT (yes, that's quite
unusual, so is using x for a different mean than what its meant for) for
the cross product.
>The whole slew of other math functions: abs, sqrt, sin, log? Where do
>they fit in? (See why multilevel vtables might be a good idea?)
Could be done here, if we were to find a reason to get the sin of a matrix
or the log of a regexp... I really don't know why these would be used in a
different mean than the usual one, but anyway...
> > // numeric ++ / --
> > void (*INC) (SVAL *result, SVAL *this);
> > void (*DEC) (SVAL *result, SVAL *this);
>
>The difference of $s++ versus ++$s is implicit?
Well, let me explain better inc/dec.
The whole idea of these ops was to use 3-arg rather than 2-arg ops. I
remember reading this on the list much before I thought of this, so I
borrowed the idea. I haven't actually thought if it's better or not,
anyway, that's why the list is here, to discuss it.
The main idea is, any operation would have the base form
a <- b op c
where b and c are arguments and a is the result. b and c, the arguments are
never modified during the operation. Based on this, I modelled all the idea
of a value on the idea of immutable and shareable. When I do something like
$a = 1;
$a += 3;
I actually fetch the value of $a (which is a sval with the numeric value
1), then I call the PLUS method of this sval, passing a sval with the
numeric value 3 as a `other operand' parameter. The vtable of the 1 sval
will then allocate a new sval, in which it will assign the resulting value,
4, and also set the vtable to handle this 4 value correctly.
The same must be done for ++. The value of the variable must be fetched,
then incremented, and the result of the incrementing of the value will be a
new value, that will be then written to the variable. As they are different
values, both the values before and after the incrementing are available, so
that both $a++ and ++$a can be handled by using the former or the latter.
> > // bit operations
> > void (*BITAND) (SVAL *result, SVAL *this, SVAL *value);
> > void (*BITOR) (SVAL *result, SVAL *this, SVAL *value);
> > void (*BITXOR) (SVAL *result, SVAL *this, SVAL *value);
> > void (*BITNOT) (SVAL *result, SVAL *this);
> > void (*BITSHL) (SVAL *result, SVAL *this, SVAL *value);
> > void (*BITSHR) (SVAL *result, SVAL *this, SVAL *value);
>
>Many new bitops have been suggested over the years: bit roll,
>bit reverse. I'm not saying they should be blindly added here,
>I'm asking what if somebody wants to?
I agree, this (as any other list of operators) shouldn't be the definitive
list. A big picture of the (renewed) language is also needed to define
which ops are needed and which are not.
- Branden
