On Wed, Dec 24, 2008 at 09:55:58AM -0600, Allison Randal wrote:
>> Within the cmp op bodies, we *know* the arity and most of the types of MMD-
>> participant arguments at compile time. We can get the types of PMC
>> participants within the body of the op itself. Thus we could avoid
>> most of the argument marshalling and counting and analysis if we had a
>> way to perform cached MMD lookup without constructing a CallSignature
>> PMC. That would clear up a third of the work.
>
> This we should open up to general discussion. The consequence of
> short-cutting like this is that individual PMCs will no longer be able
> to override 'cmp' to do something other than multi-dispatch.
Does "individual PMCs" here mean "PMC instance" or "PMC classes"? I.e.,
are you saying that a specific PMC instance could choose to override
the cmp opcode for that individual PMC? If so, do we have any examples
where this is being done now?
> At the
> moment, developers still have the option of providing their own quick
> comparison, which gives an even more extreme speedup than this shortcut.
>
> So, question for language developers and other PMC developers, how
> important is the ability to define a 'cmp' vtable function that's called
> when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your
> PMC type enough?
>From a Rakudo perspective, the ability to define custom 'cmp' vtable
functions doesn't appear to be at all important. Comparisons are
almost invariably done by invoking :multi Sub PMCs of one form or
another and letting those handle the MMD dispatch. The opcode form
seems to impose too many limitations to be used directly.
To turn the question around a bit: I can tell that a lot of work
has gone into Parrot to make MMD possible at the vtable level,
but I haven't see how vtable MMD is at all useful or usable in
languages where operator overloading is possible from the HLL itself.
And most dynamic languages I'm looking at seem to support that
in one form or another.
If someone (Allison) could make an example of how vtable MMD is
intended to improve things -- i.e., taking an HLL language
statement and showing how that translates to PIR that is improved
by vtable MMD, that would be very helpful.
> The calling conventions refactors are non-critical (some will likely
> land after 1.0), because the interface will stay the same, it's only the
> internals that will change.
Oh, I'm very disappointed to hear this. Named and positional argument
handling still has an odd behavior [*], and Perl 6 still really
needs the :lookahead option described earlier in the year. I thought
that was going to be made possible by the refactor, and is partially
why PDS had "calling conventions" schedule for the December 2008 release.
[*] Currently named parameters are filled from any leftover positionals
in the argument list -- there's no way to declare an argument that
can _only_ be filled by name, short of defining a :slurpy array
that grabs any "extra" positional arguments and then checking
that the slurpy is empty.
And, Jonathan can correct me on this if I'm mistaken, but
I suspect the other big reason that "calling convention refactor" was
scheduled for the December 2008 release is that it's likely a blocker
or important component for the custom dispatcher that Jonathan will
be creating for Rakudo as part of his funded grant. That's due to be
completed by the end of January, IIRC.
Pm
