Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
Another good reason to use pmc->vtable->fine_method in *all* lookups. So the PMC has full control over the dispatch.
How does one lookup the C<find_method> method? That will remain a VTABLE, entry right?
Yes of course.
So *all* lookups (complete with the asterisks) does not mean *all* lookups.
How about <invoke>?
All *external* names should be looked up using find_method.
Yes. But what's an external name? What happens if a Perl6 guru installs a global overloaded add function:
multi sub *infix:<+>(Int $l, Int $r) { ... }
for example to count all "add" operations or whatever. This can currently be done with the C<mmdvtregister> opcode. But that installs only one MMD function for one type pair. What if some classes inherit the "__add" method from C<Int>. Or:
multi sub *infix:<+>(Any $l, Any $r) { ... }
which presumably would influence all Perl types.
Citing S06: "Operators are just subroutines with special names."
That statement is true for Perl. Same statement is true for Python. But the names vary based on the language.
IMCC should be independent of Perl semantics.
Doing the same overloading with prefix or postfix operators OTOH would change vtable methods. That's currently not possible because the vtable dispatch is static, except for objects where it's dynamic.
We also need to be aware that in the general case, we are talking about two lookups. One to find the language specific wrapper. And one to find the common code which backs it.
Yes, but when the HLL method is found (e.g. PyStr.index) you just call the implementation statically and adjust e.g. return values.
The second dispatch may be spelled "string_str_index",
... the second dispatch is basically not dispatch, it's a function call.
So far, I have utterly failed to get my point across.
Either all languages are going to need to adopt a common set of special names (not going to happen), or Parrot is a single language runtime, or the mechanism provided to do a language level dispatch needs to be orthogonal to the way that Parrot internal dispatches are done.
Currently, Parrot is the latter. It is the suggestion that it moves towards the previous alternative that I object to.
Why is this issue so important to me? I see a lot of things I like about Parrot, but at the moment, the notions that are baked into the core as to how classes should work is not one of them.
You can straightforwardly use Parrot's object system for attributes and methods with all stuff known at compile time, AFAIK. You basically just extend the find_method and get_attr_str vtables.
"straighforwardly"... "known at compile time"?
Python's classes are glorified hashes, populated at runtime. The are essentially anonymous and lexically scoped.
WRT find_method: S13 mentions multi subs per package or even lexically scoped. So we'll probably have to extend the method lookup anyway.
I see a change that went in today to invalidate a method cache if a store_global call is made. That presumes a lot about how find_method works internally. An assumption that will not be valid for a number of languages.
Well, the builtin method lookup system with the default find_method implementation is using it. But the cache is fully transparent.
VTABLE_xxx depends only on pointer arithmetic and dereferencing. Yes, 20% of the operations may need more, and that should be provided for, but if 80% of the calls can be done this way, the performance benefits are significant.
Please don't start arguing with estimated performance benefits. I've already shown that we can do the current MMD operations 30% faster - but with dynamic dispatch too. We need at the opcode level a dynamic dispatch. Internally the vtable call remains. I've written that already a few times.
I think that all we can agree upon here is the MMD support is both incomplete and unoptimized. Making decisions based on how this implementation performs is premature.
As you tirelessly point out, this is all internal. The way the ops are
coded in the IMCC source need not change. However, prematurely mapping
*all* method names to strings so that a second method dispatch can be
done in 100% of the cases is a premature pessimization.
Well better schemes for method overloading (e.g. in Python metaclass) are always welcome. I've proposed a scheme. And yes, it's an implementation detail.
I watched the CLR folks try to come to consensus on as simple a matter as multiple inheritance. Each language will aproach this differently. The best Parrot can hope to do is to standardize on a protocol, and to provide enough primitives to enable languages to build proper support.
[ dynclasses ]
If anybody has any issues with this plan, please let me know now.
Python specific stuff should of course move out from core. For the rest:
It depends. If you end with a duplicate of CPython's Objects directory interoperbility will be difficult.
If interoperability is defined as implementing a language independent protocol, then interoperability won't be a problem.
If interoperability is defined by adopting exactly the Perl mechanisms for defining classes and adopting exactly the Perl names for methods, then, yes interoperability will be difficult.
- Sam Ruby
