Sam Ruby <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> There is of course a test case. I have mentioned it at least 20 times ;) >> t/op/gc_13.imc - currently using lexicals.
> $ parrot t/op/gc_13.imc > 3 * 5 == 15! > What's broken? By using lexicals it works now. > The current delegation internals are not likely a good match for > languages like Python or Ruby. I see such languages as implementing > their own semantics for classes, and Parrot limiting its knowledge to > methods like findmeth and invoke. Another good reason to use pmc->vtable->fine_method in *all* lookups. So the PMC has full control over the dispatch. >>>... What do we benefit from the premature >>>pessimisation of mapping this to a string? >> >> Well, method names happen to be strings ;) > Using the table below, at the moment, there are exactly zero strings > materialized and/or compared against during the execution of vtable/PMC > methods. I don't get that sentence. > ... To the extent that these are represent common operations, this > can be significant from a performance perspective. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ha? *SCNR* >> I'm proposing that *internally* (implementation detail ...) one scheme >> should be enough. Again: the opcodes don't change. > I don't think that there can be a single dynamic mechanism that works > for all languages, let alone one that works for Parrot internals too. What's wrong with the find_method vtable? > For starters, "findmeth" is a method. One that merits its own VTABLE > entry (otherwise, how would you find it?). Exactly. The "find_method" vtable is responsible for locating the method. As such it can't be overloaded directly. The "find_method" vtable is part of the meta-class system inside PMCs. The meta-class for Parrot standard objects is ParrotObject which handles the "find-method" by calling code in objects.c. If that dispatch scheme doesn't fit at all for a language it can of course create it's own meta-class with an appropriate "find_method" vtable. The important thing is that from the opcode level all continues to work as long as the opcodes are using "find_method". > MMD might help out with mutiple language interop, but Python as > currently designed doesn't need any such facility. That's not quite true. CPython has a rather bulky manual dispatch to find the correct operation for e.g. "long + int". The result is totally the same with Parrot's MMD dispatch - find a possibly internal function that is able to add a long integer and a normal integer. You can now of course duplicate the whole standard PMCs and roll your own code. But that's error prone and increases code size for no good reason and it will verly likely not help for HLL interoperbility. > I asked my question poorly, and I think you answered it, but the > important point is that subroutines can change the lexical variables of > their callers - enough so that either a second level of indirection is > required The second level is the name hash. Nothing changes here. If the compiler knows the lexical it can currently emit code with an indexed access to the lexical data array. This corresponds to an indexed access inside the register store. If the lexical isn't known because it's somewhere in an outer pad (or it's even created dynamically) the hash lookup jumps in, as now. > - Sam Ruby leo
