Sam Ruby wrote:
[ a lot - I'll split answers ]
Leopold Toetsch wrote:
Sam Ruby wrote:
It seems obvious, but it leads to surprises. Example:
'1' + '2'
The result will depend on what the actual types are of the inputs
perhaps even what the context is of the caller.
Ehem, given that and ... (from below)
> Note: no MMD.
> and VTABLE_add()
it seems that you are still missing the power of MMD. Just because the
result and semantics of the "add" operation are different, we are doing MMD.
The MMD dispatch looks at the left and right types of the infix
operation, locates a function that matches and call the function.
You can look at it like a matrix:
PyString PyInt PyNum Integer ...
----------------------------------------------------------
PyString py_add_s add_err add_err add_err
PyInt add_err add_i add_n add_i
PyNum add_err add_n add_n add_i
Integer add_err add_i add_n add_i
...
There are four incarnation of the "add" multi sub:
py_add_s := concat (function name Parrot_PyString_add_PyString)
add_err := emit a "TypeError : cannot concat ..."
add_i := integer add (Parrot_Integer_add_Integer)
add_n := float add (Parrot_Float_add_Float)
So what actually need to exist in Python scalar classes is a constructor
and:
in pystring.pmc
pmclass PyString extends PyObject extends String {
METHOD PMC* add(PMC *right) {
MMD_PyString: { ... do a concat }
MMD_DEFAULT: { ... emit TypeError }
}
}
in pyint.pmc (and pyfloat analog)
pmclass PyInt extends PyObject extends Integer {
// inherit add
}
The METHOD specifier shall install all given variants with
VTABLE_add_method, i.e. register the NCI functions so that
VTABLE_find_method can locate the entry.
But the matrix implementation doesn't work, because it's too static,
inheritance can't be described easily (or not at all) in terms of it.
As my proposal is primarily focused on where the logic is placed
And that's the main problem of your approach. You are forgetting MMD.
inline op add (out PMC, in PMC, in PMC) :base_core {
$1 = VTABLE_add(interp, $2, $3);
}
With that you are already calling an "add" function that depends on the
left type - this is not MMD and it forces the left operand to handle
all possible cases of add/concat with int/float/string ... This is
exactly the point, where interoperbility is violated. The left type
doesn't know all possible right types to deal with them correctly.
With that you get a cascade of "if"s that handle the different types. We
had that earlier. It was discarded in favor of MMD.
pmclass default abstract noinit {
PMC* add (PMC* left, PMC* right) {
PRESERVE_CONTEXT;
add_func = mmd_find("__add"...) // via VTABLE_find_method
and here it becomes horribly slow and weird. You are already in one
"add". What do you want to find here?
REG_PMC(5) = left;
REG_PMC(6) = right;
VTABLE_invoke(interp, add_func, 0);
and redispatching - no and no - sorry.
I know that Leo keeps telling me that I need to map __add__ to __add at
"compile time", but there are tests like t/pie/b3.t that indicate that
such tests need to be made at runtime.
When I say, that "__add__" maps to Parrot's "__add" at compile time, it
doesn't preclude that you have to do something at runtime too. E.g. you
emit code for:
foo.__add__ = myadd (or __dict__.__add__)
then the user is installing an overridden version of the "add" method.
You have to know that, or you can't do the right thing when it comes to
foo + x
So you have to call
VTABLE_add_method(class_of_foo, "__add", myadd).
If you don't do that, VTABLE_find_method(... "__add") will fail later or
return the wrong function.
But and that's the big difference of our porposals: nothing more has to
be done. The MMD dispatch at the runloop (and not inside every class)
handles the selection of the correct subroutine, being it a C function
(wrapped into NCI) or PASM/PIR user code. This just doesn't matter and a
class doesn't need to know about that.
Allowing me to subclass, extend, and replace how methods like add works
gives me a place to insert any logic I find necessary.
Which logic would you insert in add(PyInt, PyInt)? What for?
... And, when I find
out that something is not as necessary as I once thought, it can be
removed just as easily.
No because you are duplicating the method dispatch. You can't remove
that. And that's the big problem with your approach - besides that it'll
be around a factor 10 slower then the dispatch at the opcode level like
now. We can't afford a factor ten in speed decrease.
Arguements can be made against each individual example (perhaps I could
create a small function that raises Type Error and register it dozens of
times to handle the PyString.add example, and yes,
Instead of the check (if right.type isnt a PyString) you are already in
the MMD method Py_String_add (_default) - "add_err" above - no check
needed. That's MMD.
... I could make every
assignment to any Python property invalidate some portion of the method
cache,
You have to call add_method anyway, if a Sub is attached to some
attribute (with special names). And add_method is the place where the
cache for that class is invalidated.
...but that still wouldn't handle cases where two objects were of
the same class but respond differently to find_method).
You are calling VTABLE_find_method(interp, object, ...) This is exactly
the place to look at that object's properties, then you call find_method
on the class ...
- Sam Ruby
leo
|
