Re: Re[2]: Still cryptic OOP syntax

[skaller <skaller@...>]

On Mon, 2005-01-31 at 13:57, David Olofson wrote:

> > 
> > I.e. it should treat
> > 
> >  a + b
> > 
> > just the same way it treads
> > 
> >  add (a,b)
> > 
> > right now. The standard library would predefine 'add'
> > to work just the same as 'a + b' does right now..
> 
> Well, that would just be an implementation detail. 

Indeed. However the goal is to obtain an extensible language
with better polymorphism. Ultimately doing that does
require a concrete proposal for some code .. :)

> At least, EEL calls C and EEL functions the same way, 

Yes, but Lua does not. More precisely it has to lookup
the function by name at some point, and the function,
if defined in C, has to have the Lua C function interface.


> To install a bytecode operator, on would just set the bytecode 
> function pointer to it, and then point the C function pointer to a 
> function that performs a VM call instead of actually performing an 
> operation. No performance penalty for native implementations!

You're missing the point though. Even if a C function were
called, it is unlikely to be as efficient as the current 
Lua bytecode interpreter adding Number + Number because that
case is specially treated:

      case OP_ADD: {
        TObject *rb = RKB(i);
        TObject *rc = RKC(i);
        if (ttisnumber(rb) && ttisnumber(rc)) {
          setnvalue(ra, nvalue(rb) + nvalue(rc));
        }
        else
          Arith(L, ra, rb, rc, TM_ADD);
        break;
      }

Arith() is messy, it calls another function which tries
metamethods. But for a native Number type the code involves
two types checks and this line:

          setnvalue(ra, nvalue(rb) + nvalue(rc));

which is basically a native C level + operation.

The point being that without some care of the implementation
details, a more general system might degrade performance
of 'the usual case' significantly which probably isn't acceptable.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net