Leopold Toetsch wrote:
You'd need in pyclass.pmc:
PMC* get_repr() { return pmc_new_string( ... "<class ...>") }
In this case, there is a Python specific default. In other cases, there are other Python specific behaviors like mapping not found to an exception or to None. In short, I don't see wrappers going away.
Yes, I already said that some methods might need either a wrapper or just simpler the class implementes the method.
The problem with you code is: you call again VTABLE_find_method and then, if a method is found, run_meth_fromc_args. This is already done by Parrot eventually, you are already in PyClass.__repr__. No redispatch is needed, just return a string.
get_repr is overloadable. Being overloadable is the norm rather than the exception in Python.
Yes, of course. But that's part of the dispatch that Parrot is doing, not part of *each* method in PyClass or such. If get_repr was overloaded then Parrot runs the user code.
Again:
STRING* get_repr() {
PMC *repr = VTABLE_find_method(INTERP, SELF, REPR); if (repr) {
PMC *temp = Parrot_run_meth_fromc_args(INTERP, repr, SELF, REPRThis part is done in the run-core. The HLLs part is to install a function with add_method that is found if needed.
* Parrot knows common type names (Integer, Float, String, Bool, ...) of the supported languages
The alternative (which is supported today) is that callers pass in a PMC which defines a morph method which maps common type names to language specific alternatives.
Well and this scheme doesn't match overloaded methods. So we'd have two different calling conventions, which of course would need glue code to make them compatible. We don't need that glue code or wrapper, if overloaded function syntax matches the internal C implementation.
The advantage of what exists today is that adding a new language does not require any changes to Parrot. The caller defines the mapping.
Such a mapping is easily extendible. New languages aren't added silently, Parrot needs to know a few bits about the HLL.
* all dispatch is based on VTABLE_find_method
Just to be clear, in the cases where a wrapper is needed (which I would argue is the majority of cases), this works out to be: a call to VTABLE_find_method for the wrapper which in turn uses VTABLE_find_method to access the "real" logic.
No. VTABLE_find_method locates the very method that should be run. Being it a C function or a user provided subroutine. So when e.g. Parrot_PyInt_divide_PyInt is called, you know exactly the class (in case of MMD both classes). As you know that the base class is Integer, you can just call the baseclass function directly, if you desire so.
A user can't insert another __bases__ in core classes, so that's save.
For overloaded methods again the pair add_method/find_method is doing the job. If the result of find_method is a Sub PMC, the run-core runs the function.
Again, just to be clear: this hinges on dual assumptions: (1) that wrappers aren't needed in the majority of cases,
Yes. Basic mathematical functions are just the same in Python or Perl6 or whatever.
... and (2) every time someone gets or sets a method, a mapping can be done from language defined names to Parrot conventions.
Of course. How else would you be able to overload "add Px, Py, Pz" if you can't detect that certain manipulations of attributes have that effect?
Note that in Python, all attributes may potentially be a method.
Yes. Your implementation of find_method has to cope with it. You need that anyway.
- Sam Ruby
leo
