At 02:33 PM 2/7/2001 -0500, Buddha Buck wrote:
>At 01:14 PM 02-07-2001 -0500, Dan Sugalski wrote:
>>At 01:35 PM 2/7/2001 -0200, Branden wrote:
>>>As far as I know (and I could be _very_ wrong), the primary objectives of
>>>vtables are:
>>>1. Allowing extensible datatypes to be created by extensions and used in
>>>Perl.
>>
>>Secondarily, yes.
>>
>>>2. Making the implementation of `tie' and `overload' more efficient ('cause
>>>it's very slow in Perl 5).
>>
>>No, not at all. This isn't really a consideration as such. (The vtable
>>functions as desinged are inadequate for most overloading, for example)
>
>Hmm, I seem to remember vtables were being cited as a cure for lots of
>ills (perhaps combined with other aspects, like "make Perl nearly as fast
>as C".)
Yep, and they'll wash your windows and do your laundry, too. :)
>The vtables were implied (or possibly out-right stated) as giving the
>low-level core a more object-oriented structure: as you state below,
>branching and conditionals in the runtime can be eliminated by the values
>knowing how to operate on themselves.
>
>It was also implied (or out-right claimed) that different
>objects/classes/packages/whatever could have class-specific vtables,
>defined at run-time, that would be used to handle the class-specific
>implementation details. I'm not sure what that could refer to except ties
>and overloading; class-specific methods wouldn't go in the vtable.
While defining tie and overload functions will affect the vtable generated
for a package, users generally won't be writing all the vtable functions,
nor will they be writing directly to the vtable spec.
The current list of functions defined as needed for tieing and overloading
are sufficient, with some glue, to build up a fully functional vtable. I
really, *really* don't want people skipping the tie or overload interface
and heading straight for the low-level vtable interface, since they'll be
really screwed if we change how vtables are defined or work, or scrap them
altogether.
>There was some discussion that allowing the vtables to refer to functions
>written in perl would be a good idea, as it would allow extensions to be
>written in perl -- which is a good thing.
>
>I had gotten the impression that the perl code-sequence:
>
> $a = $b + $c;
>
>would generate the same op-code sequence regardless of the type of $a, $b,
>$c, and the vtables would do all the magic behind the scenes, calling tied
>or overloaded versions of the base functions if so defined for $a, $b, or $c.
Unfortunately overloading presents certain problems. Generally speaking
we're OK if a custom variable behaves as if it were a builtin type, but
when it doesn't the vtable scheme isn't sufficient.
For example, this:
@foo = 12 * @bar;
will cause problems if @bar is an odd type. We'll be using 12's vtable (the
integer one) as the source of the functions to do things, while it's
actually the right-hand side that's messed up.
With some things, + and * particularly, we can probably get by with some
arithmetic reordering. With - and /, though, we can't since those
operations aren't commutative. Because of this, unless Larry says "Left
hand side wins for custom types", we need more support than is in the
vtable definitions to manage things. That support will be provided by the
compiler, assuming you write to the tie or overload interface and not
directly to the vtable interface.
>Now I seem to be hearing that this is not the case, that variable ties and
>overloads are at a much higher level, never touching the vtables. It now
>seems that the vtables will exist only for built-in types, and be
>inaccessible for user-defined types (unless those types are defined by the
>perl6 equivilant of XS, for example). This almost seems to be defaulting
>on the promise of vtables I thought was made
It will be possible to write full vtables in perl--that's one of the things
that Larry wants. (He wants to be able to call perl subs like C functions,
so it pretty much follows)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
