Sam Ruby wrote:
Leopold Toetsch wrote:
The caller sets:
mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth
In the general case, how does the caller know that MMD is invoked?
Perl6 "multi sub"s are denoted with the "multi" keyword. We need some extensions to pdd03 that pass this information on to Parrot. It basically boils down to a new opcode:
call_MMD "method", n
as described in subjects "MMD: more implications" and "MMD dispatch"
My question was: how does the caller make such a determination?
Yes, in Perl 6, the "multi subs" are defined with the "multi" keyword.
However, from <http://www.perl.com/pub/a/2004/04/16/a12.html?page=10>:
Whenever you make a call using subroutine call syntax, it's a
candidate for multiple dispatch.I read this to mean that the *caller* does nothing to distinguish between calls to single dispatch subroutines from multiple dispatch subroutines.
So... how does one determine at compile time which opcode to use?
A cache invalidation function is called from add_method (and remove_method) which resets entries for the passed class.
And, in some languages, all calls to set_attr or setprop type methods, where the value invoked may be invokable, or might obscure visibility to one that is. As calls to setting attributes/properties are frequent, my concern is that this may more than wipe out any potential benefit that such a cache may provide.
You don't have operator overloading implemented in py*, do you? Anyway the code generator emits:
add Px, Py, Pz
Now some attribute set operations on the class, metaclass or in the "__dict__" can mean an overloading of the "__add__" method of C<Py>. To handle that correctly, you can either not emit an "add" opcode in the first place, or you have to track the attribute set operations so that you are able to call the user-provided "__add__" method.
You can of course in the current scheme install an "add" MMD method that does always a full method lookup, but then you got the performance problem you are worrying about.
The overloading functionality has been added for a number of methods, but not yet for __add__. I've been adding methods one at a time based on the existence of test cases.
Classes like PyString are primitive, and opcodes like get_iter directly access the vtable.
For classes written completely in PIR, the vtable entry for get_iter causes __iter__ methods to be invoked. Note: this decision is made at runtime, not at "compile" time. Instead of pessimistically assuming that all such invocations will require a method lookup, this decision is deferred to the appropriate implementation of VTABLE_get_iter.
Classes written in PIR but inherit from primitive classes employ a proxy, analogous to the delegate class, but in reverse. Note: proxies are only created if there is such a mix of PIR and NCI involved.
All of this is taken care of by the C<invoke> methods of PyType and PyProxyType, the compiler is unaware of these details.
Also, note that the Perl sub defined above is not a method.
Yes. But Perl6 allows multi subs to be called as methods on the first invocant too:
$a.foo($b, $c) := foo($a, $b, $c)
Given the latter syntax, how does the compiler know when to emit a <callmethodcc "foo"> and when to emit a <call_MMD "foo">?
Comments welcome,
Counter-proposal.
I see no reason why a full multi-dimensional multi-method dispatch PMC could not commence immediately, complete with a fully-functional polymorphic inline cache. Once it is ready and tested, we can explore setting things up so that the various mmd_dispatch_* functions to exploit this functionality for the existing predefined binary operations.
I don't see how this solves anything, except that you seem to be moving the burden of MMD to an additional PMC. What does this proposed MMD PMC do? How does it find the appropriate multi-method?
I've described a versatile MMD scheme that is able to do n-dimensional MMD. Counter-proposals are very welcome, but the proposal has to include the mechanism how it works. A "MMD PMC that does it" is too thin, sorry.
The only thing I am attempting to solve is the presumption that MMD calls can be detected at "compile time".
Unless you can describe a mechanism which enables the callers to detect
at "compile" time whether they are invoking a MMD subroutine or not, this code needs to be either executed as a part of an VTABLE_invoke.
Again, I am not suggesting that the algorithm be made any "thinner", in fact, I am not suggesting any change to the algorithms that you have described. I am merely suggesting where the logic needs to be placed.
- Sam Ruby
