Hi all-
I have been checking the Python source code (something I am sure all of you
already have done :-) and some differences on the design surprised me so
much that I decided to come and make some questions.
I guess that most of you know well the python source code, so please
apologize the lengthy mail.
I focused on reviewing the implementation of PythonObjects (Python's PMC)
and found some interesting points that I would like to discuss with this
list.
These are:
I. Missing methods in parrot:
The are many vtable methods in python not present in parrot. Some of the
ones I would expect to really be needed are:
* divmod # integer division
* power
* absolute
* invert
* compare
And probably many others.¿Is there any reason not to have this ones at
least?
They've got also a bunch of methods for things like calling builtin methods,
getting and setting object attributes, and so on. But I guess these ones
should better stay out until that part of the design is more advanced.
BTW, ¿do we have any idea of how will user-defined objects look like? ¿Will
methods be object's attributes, or just a funny syntax to call functions?
¿Will
Parrot allow user-defined class to inherit from builtin-classes (another
Python's
requirement)?
II. The "protocols" concept
In Parrot, there is a single vtable structure for objects. Python, in the
other hand, defines a set of protocols that are optionally
implemented by objects (Number, Sequence, Mapping, Buffer and Iterator I
think).
Objects that implement the Number protocol have a non null entry on the
main vtable called tp_as_number that holds a pointer to yet another vtable
with the number-relatad methods.
This allow for easy checking if an object can be operated numerically (just
test pmc->vtable->as_number != NULL) but adds yet an indirection level
(pmc->vtable->add gets pmc->vtable->as_number->add)
I cannot tell what other design or performance benefits produces the choice
of putting so frequently used methods in a deeper indirection level but
would love to listen from those who know more.
III. A different solution for coercion
In Parrot, we currently define a new family of methods for each type of
number (or string btw). So we have:
void add (PMC * value, PMC* dest)
void add_int (INTVAL value, PMC* dest)
void add_bigint (BIGINT value, PMC* dest)
void add_float (FLOATVAL value, PMC* dest)
void add_bigfloat (BIGFLOAT value, PMC* dest)
void add_same (PMC * value, PMC* dest)
If we wanted to a add a new number or string type (for instance a Complex
type), then we should create a new family of add_complex, subtract_complex,
etc.. methods, and implement them on each PMC class.
Intuition tells that this cannot be the best way to handle this problem.
Python's solution is to define an intermediate function (let's call it
Perl_NumberAdd) that implements the coercions between numbers, so the PMC
is only responsible of implementing the "add" method with an object of the
same type (what is currently add_same)
This simplifies very much the creation of hierarchy of types for numbers,
and localizes the changes to make when a new number type is introduced.
Additionally, in the specific Parrot case (where we want to execute code of
different programming languages) I would say that this is the only way to do
the right thing, because the same mathematical operation can require
different coercion polices for different languages. (Think on perl, who
automatically converts strings to numbers when performing an "add", against
python, who would raise a type error).
So it looks to me that coercion doesn't belong to the object domain, but to
the language domain, (since a number born in perl could easily end up in
python) and thus its code shouldn't live in the vtable but in the opcode (or
a
function called by it), and that we should have two different opcodes for
python's add (py_add), and perl's add (perl_add).
To sum up: kill all the exotic versions of add, subtract and friends, and
implement coercion in a per-language function, that gets called by a
per-language opcode version.
--
I am honestly not very sure to make much sense in any of these, and I am
more than willing to learn why our way is better than their's, if that's the
case. On the other hand... who knows.
If any of this pythonesque influences haves some interest for Parrot, (I am
particulary interested in the third one) I would volunteer to contribute a
patch attempt for it.
----------------------------
Angel Faus
[EMAIL PROTECTED]
