Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Am Donnerstag, 30. November 2006 01:20 schrieb Matt Diephouse:
Matt Diephouse [EMAIL PROTECTED] wrote:
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.
It ended up being easier than expected -- implemented in r15910.
Looks good and works as expected.
BTW: the subject is a bit misleading, MMD and auto{un,}boxing are really
orthogonal, the former selects a sub depending on call argument types (and
available multis), the latter deals with argument passing to the one select
sub.
Great job, thanks
leo
Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
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. leo
Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
On Wed, Nov 29, 2006 at 08:49:27PM +0100, Leopold Toetsch 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. Just to repeat my comments from #parrot, I agree with Leo that treating int as always (and only) being identical to the autobox type feels very wrong somehow. However, if we're short-term restricted to choosing between the existing implementation (where '_' doesn't match native types) and this patch (where we can't differentiate native types), I definitely want the patch. It's the lesser of the two evils. IWBNI the native types were considered in both their native and autoboxed aspects for purposes of selecting candidate MMD subs, with a match on native types resulting in a shorter MMD distance than those involving autoboxing. Pm
Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
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? Is there a specific case you have in mind? -- Matt Diephouse http://matt.diephouse.com
Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
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 If I understand things correctly, specifying :multi(_, String) doesn't actually do any form of coercion, it simply says that this sub is called only if the second argument is compatible with the String type. This is true even if we have a :multi with a native type: .sub 'bar' :multi(int) .param pmc abc ## abc is an autoboxed int for us here, even though this ## sub can only be reached if the (single) argument ## is an integer register or integer constant ... .end .sub 'baz' :multi(pmc) .param string def ## Baz can only be called with a pmc argument, and that ## pmc (whatever it is) is auto-unboxed into a string register. ... .end 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). Now then, for purposes of selecting the sub(s) to call, :multi can take into account the fact that native arguments can autobox, and call a sub that specifies the autoboxed type in :multi (but preferring a sub with the native type in :multi, if one exists). And I don't think :multi should go the other way -- i.e., to assume that a boxed type will match a native type in :multi. With what I just described there's already a way to get that semantic, namely: .sub 'foo' :multi(Integer) .param int xyz ... .end With this, a foo(1) or foo($I0) call will still find the sub, but won't do any boxing or unboxing. If foo is called with an Integer pmc argument, :multi will find the sub, and the Parrot calling conventions will end up autounboxing the argument into an 'int', which is what we wanted. And if foo(...) is called with something that isn't compatible with Integer (e.g., a subclass), then :multi won't select this sub at all. But as I said, I'm no expert -- this is just my best stab at how things ought to work, at least in the short term until a more sophisticated Parrot object model is in place. And as I also indicated, I don't have nearly as strong feelings about this as I do about the fact that we need a way to specify 'any type' (including native types) in the :multi pragma. Thanks, Pm
Re: Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
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
Re: Re: Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Matt Diephouse [EMAIL PROTECTED] wrote: 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. It ended up being easier than expected -- implemented in r15910. -- Matt Diephouse http://matt.diephouse.com
[perl #41014] [PATCH] Autobox Native Types for MultiSubs
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #41014]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41014
This patch address #40968: [BUG] underscore as :multi arg doesn't
work as expected.
Rather than change _ to mean any pmc or any native type in a :multi
signature, I've matched native types using their autoboxed PMC types.
That means that this now prints ok:
.sub main :main
test('ok')
.end
.sub test :multi(String)
.param string str
say str
.end
.sub test :multi(Integer)
.param int num
say num
.end
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.
This patch also patches all the uses of string, int, and float in the
Parrot tree, replacing them with String, Integer, and Float. It does
not affect the MMD infix operators.
--
Matt Diephouse
mmd-autobox.patch
Description: Binary data
