Jarkko Hietaniemi writes:
: What is someone wants to define matrices and have both cross product
: and dot product?

At some point, there aren't enough operators, and new ones have to
be named somehow, or old ones usurped.  In any event, new ops either
have to be declared with a lexical scope, or use an existing syntactic
rule.  But the underlying operation can still be dispatched like a method.

: 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?)

I don't see how a multilevel vtable saves us either time or memory.

: >       // 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 think it's a mistake to think of the vtable format as fixed.  We need
ways to install sets of methods such that they'll dispatch just as fast
as any built-in.  This probably involves setting up some kind of a
registry for mapping of names to vtable offsets at compile time, for
those method names we know about at compile time.

: >       // numeric comparisons
: >       int   (*NUMCMP)     (SVAL *this, SVAL *value);
: >       int   (*NUMEQ)      (SVAL *this, SVAL *value);
: >       int   (*NUMNE)      (SVAL *this, SVAL *value);
: >       int   (*NUMLT)      (SVAL *this, SVAL *value);
: >       int   (*NUMGT)      (SVAL *this, SVAL *value);
: >       int   (*NUMLE)      (SVAL *this, SVAL *value);
: >       int   (*NUMGE)      (SVAL *this, SVAL *value);
: 
: I'm not certain about the utility of having separate EQ NE LT GT LE GE.
: If those are not deducible from CMP, we don't have a consistent comparison
: function (we might get loops).

Nevertheless, there are machines that can implement EQ faster than they
can implement CMP, or that would rather not pay the overhead of the
extra recursive method call.  A given program on a given architecture
might want to have it either one way or the other.  This is yet another
indication that nailing down the entries of the vtables is a form of
premature optmization we can't afford to indulge in.  Every class
should have its own vtable, constructed from available metadata.  If
some of that metadata is available before we even start, fine, we can
cheat some based on that.  But let's not reimplement Perl 5's
intellectual limitations.  There's no reason to relegate user-defined
functions to second-class status.

Larry

Reply via email to