Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Wed, Nov 29, 2006 at 04:43:59PM -0500, Matt Diephouse wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse:
> >> It also means that "string", "int", and "float" no longer work as MMD
> >> types -- you can't distinguish between native types and PMCs. I think
> >> this is the right way to go now that we have autoboxing; I don't see
> >> any reason to differentiate.
> >
> >I don't think this is the best strategy. It seriously prevents all native
> >type optimizations. While 'Integer' should be MMD-distancewise
> >close to 'int', it should not be the same.
>
> What native type optimizations? Using S, I, and N registers? If using
> an I register is faster, wouldn't you want to unbox an Integer PMC and
> use an I register anyway?
Sure, but Parrot is unboxing for us already, without us having
to do anything special:
.sub 'foo' :multi(_, String)
.param int abc
.param pmc xyz
...
.end
foo(1, 'xyz') # boxes 'xyz', leaves 1 alone
foo($P0, $P1) # unboxes $P0 to an int, leaves $P1 alone
That's the point I was trying to make. I can't think of any case where
you would want to have a different param type based on whether you
passed a native type:
.sub 'foo' :multi(int)
.param int abc
...
.end
.sub 'foo' :multi (Integer)
.param pmc abc
...
.end
Because what would be the point? If using a native type in the sub is
faster, then use it no matter what: unbox the PMC. If it's not faster,
then there's no optimization and you may as well autobox to a PMC when
a native type is passed in.
I'm not at all an expert on the topic of multis, but it sounds to
me as though :multi is being somehow conflated with "when to
auto[un]?box". I think :multi should limit itself to being a way
of selecting which sub(s) to call, while autoboxing should be
based solely on the arguments of the caller and parameters of the
called sub (once that sub has been chosen by :multi).
Even with the patch, :multi "limits itself to being a way of selecting
which sub(s) to call", so no worries there.
It's not that I have my heart set against dispatching on native types,
but I would like to see a reason for it. Leo mentioned optimization,
but I don't see how that applies.
We've basically run into the fact that there's no spec for MMD. I'll
see if I can provide a patch that just makes "_" match native types,
but I think it'll be somewhat more involved than this one.
--
Matt Diephouse
http://matt.diephouse.com
