VTABLE methods and interfaces

19 views
Skip to first unread message

Leopold Toetsch

unread,
Feb 23, 2005, 9:56:44 AM2/23/05
to Perl 6 Internals
There was already some discussion about splitting the VTABLE structure
into distinct pieces. I'd like to start that task after 0.1.2 is out.

Here are some thoughts:

1) Vtable and interfaces

The VTABLE structure provides common slots that every PMC must provide
and optional parts that roughly correspond to an interface. E.g. a
scalar doesn't need the array slots push, pop, shift, unshift ... But an
array should fill these, but not the scalar entries like get_number.

Each of the optional interface parts in the VTABLE is just a pointer to
a structure holding the entries (or to a default implementation that
catches errors for unhandled interfaces) This adds one indirection to
most of the vtable calls but it reduces the size of the vtable vastly.

2) Vtable entries should be real methods

All non-defaulted, non-inherited entries of a vtable interface should be
available as methods, like now with the METHOD keyword. This allows
eventually code like this:

Px = Py."__pop_pmc"()

or

Px = Py."__string"() # $x = ~$y string kontext

This easily allows overloading of all the vtable methods. The PIC code
gets even rid of the additional indirection as the function is called
directly from opcodes. The vtable slots are just for calling these
methods from within C source.

3) MMD functions

They work basically like other methods except that there is no VTABLE
slot and the method lookup is more complicated. The more detailed (and
very preliminary) proposal below has some additional MMD functions that
we'll need (IMHO):

"__i_add"(Px, Py) # $x += $y
Px = "__n_add"(Py, Pz) # x = y + z ; x is newly created

The distinct slots for the inplace operations are at least necessary for
Python, as these are separate methods in Python. It also simplifies the
implementation as a check for "self == dest" isn't necessary in the
plain operations.
The variants with an "n_" prefix create and return a new PMC.

Comments welcome.
leo

VTABLE.txt

Sam Ruby

unread,
Feb 23, 2005, 2:03:30 PM2/23/05
to Leopold Toetsch, Perl 6 Internals
Leopold Toetsch wrote:
>
> 2) Vtable entries should be real methods
>
> All non-defaulted, non-inherited entries of a vtable interface should be
> available as methods, like now with the METHOD keyword. This allows
> eventually code like this:
>
> Px = Py."__pop_pmc"()
>
> or
>
> Px = Py."__string"() # $x = ~$y string kontext
>
> This easily allows overloading of all the vtable methods. The PIC code
> gets even rid of the additional indirection as the function is called
> directly from opcodes. The vtable slots are just for calling these
> methods from within C source.

As long as find_method itself can be overridden, this above is merely a
description of the default behavior, not a hard requirement.

> 3) MMD functions
>
> They work basically like other methods except that there is no VTABLE
> slot and the method lookup is more complicated. The more detailed (and
> very preliminary) proposal below has some additional MMD functions that
> we'll need (IMHO):
>
> "__i_add"(Px, Py) # $x += $y
> Px = "__n_add"(Py, Pz) # x = y + z ; x is newly created
>
> The distinct slots for the inplace operations are at least necessary for
> Python, as these are separate methods in Python. It also simplifies the
> implementation as a check for "self == dest" isn't necessary in the
> plain operations.
> The variants with an "n_" prefix create and return a new PMC.

I continue to believe that it is not a good idea for Parrot to decide
apriori exactly which methods are to be mmd universally for all
languages and all objects.

- Sam Ruby

Leopold Toetsch

unread,
Feb 24, 2005, 3:40:35 AM2/24/05
to Sam Ruby, perl6-i...@perl.org
Sam Ruby <ru...@intertwingly.net> wrote:

> As long as find_method itself can be overridden, this above is merely a
> description of the default behavior, not a hard requirement.

Yes, of course. C<find_method> *is* overridable and, as all method lookup
is calling C<find_method>, the code can do whatever is needed. I'm
describing the default implementation of Parrot, which should be a
reasonable base for the target languages.

> I continue to believe that it is not a good idea for Parrot to decide
> apriori exactly which methods are to be mmd universally for all
> languages and all objects.

Again that's Parrot's default implementation performed via
C<find_method> (or the extensions to the method lookup, I've outlined in
several threads).

It's up to C<find_method> to perform a MMD-ish lookup - or not. But
given that PyPy is using MMD, I see no reason for Python on Parrot not
to use MMD for the infix operators. MMD saves cascades of "if"
statements checking the right operand's type.

> - Sam Ruby

leo

Kevin Tew

unread,
Apr 16, 2005, 12:30:30 AM4/16/05
to perl6-i...@perl.org, Sam Ruby, Perl 6 Internals
Sam,

Just wondering what the status is on python/parrot/pirate/pyrate.

These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/

Is there a up to date cvs repo?
Can we get this code checked into the parrot svn repo?

Kevin Tew

Reply all
Reply to author
Forward
0 new messages