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
=head1 TITLE
Vtable and Interfaces
=head1 ABSTRACT
Every PMC and Parrot Class has a distinct vtable. Additionally a
shared or read-only variant of a PMC or class needs a different
vtable. But by far not all vtable slots are used by all classes.
To improve memory usage and flexibility this proposal describes a
split of vtable functionality.
=head1 DESCRIPTION
A vtable gets split into different parts: common funtionality that
each PMC must provide and optional interface parts.
=head2 Common vtable entries
=item instantiate, mark, destroy, finalize, freze, thaw ...
=item type, mro, name, find_method, isa, does, can
=item cmp, hash
=head2 Scalar PMC entries
=item add, subtract, multiply, ... MMDs !
Use an existing destination.
=item nadd, nsubtract, nmultiply, ... MMDs !
Create a new destination.
=item inc, dec
=item iadd, isubtract, ... MMDs !
Inplace operations C< a += b >.
=head2 Native scalar entries
=item get_integer, get_number, ..., add_int, multiply_int ...
=head2 PMC array entries
=item get_pmc_keyed, push, pop, shift, unshift, splice
=head2 Native array entries
=item get_integer_keyed ...
=head2 PMC hash entries
=item get_pmc_keyed, exists_keyed, delete_keyed
=head2 Native hash entries
=item get_integer_keyed ...
=head2 Object entries
=item get_attribute, set_attribute, ...
=head2 Iteration slots
=item get_iter, iter_next
[plaintext VTABLE.txt]
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
Sam Ruby <rubys@no-spam> 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
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