Skip Menu |
Report information
Id: 71536
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: masak <cmasak [at] gmail.com>
Cc:
AdminCc:

Severity: Wishlist
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [BUG] Rakudo allows two multi variants with the exact same signature to be defined
Date: Tue, 22 Dec 2009 08:28:46 +0100
To: rakudobug [...] perl.org
From: Carl Mäsak <cmasak [...] gmail.com>
Download (untitled) / with headers
text/plain 491b
This be Rakudo 8dc189. $ perl6 -e 'multi sub f($a) {}; multi sub f($a) {}; f(42)' Ambiguous dispatch to multi 'f'. Ambiguous candidates had signatures: :(Any $a) :(Any $a) The definition of two variants with equivalent signatures (i.e. identical up to names) can, and IMHO should, be caught statically. Unless/until there is some excellent introspection into where clauses, there are limits to the signature comparison that can be made, but at least the simple cases should be no problem.
CC: Perl6 <perl6-language [...] perl.org>
Subject: Re: [perl #71536] [BUG] Rakudo allows two multi variants with the exact same signature to be defined
Date: Tue, 22 Dec 2009 11:22:53 +0100
To: perl6-compiler [...] perl.org
From: Moritz Lenz <moritz [...] faui2k3.org>
Download (untitled) / with headers
text/plain 767b
Carl MXXsak (via RT) wrote: Show quoted text
> This be Rakudo 8dc189. > > $ perl6 -e 'multi sub f($a) {}; multi sub f($a) {}; f(42)' > Ambiguous dispatch to multi 'f'. Ambiguous candidates had signatures: > :(Any $a) > :(Any $a) > > The definition of two variants with equivalent signatures (i.e. > identical up to names) can, and IMHO should, be caught statically.
I've wondered about that too, and for multi methods it can make sense to have two multis with the same signature, for example for usage with .+ and .* Is there a way to call multiple multi subs? Show quoted text
> Unless/until there is some excellent introspection into where clauses, > there are limits to the signature comparison that can be made, but at > least the simple cases should be no problem.
agreed. Cheers, Moritz
Download (untitled) / with headers
text/plain 1.8k
Discussion from IRC precises this ticket to be related to multi subs not multi methods. [12:34] <masak> bbkr: it's probably not spec, no. but I think it's common sense. [12:34] <masak> I invoke "things that can be caught at compile-time, should be" [12:35] <jnthn> If the spec doesn't say we must, then it's not a bug. [12:35] <jnthn> It's a worthwhile feature request though. [12:35] <jnthn> So, it shouldn't have the bug tag. [12:35] <jnthn> But it's an OK ticket. [12:36] <jnthn> Perhaps one of those things the optimizer can spot. [12:36] <jnthn> Or maybe we do it at czech time [12:38] * masak removes the [BUG] tag [12:41] <bbkr> I agree with moritz here - having multis with the same name and signature is perfectly fine. That can be used in any plugin implementation, for example "role Twiitter { multi method broadcast( Str) {} }; role Facebook { multi method broadcast (Str) {} }; class Social does Twitter does Facebook {}". compile error in this case is harmful. [12:43] <benabik> bbkr: You expect it to invoke both? [12:43] <jnthn> bbkr: It's important to distinguish multi methods and multi subs here. [12:44] <jnthn> bbkr: The multi method case is potentially useful. The multi sub case can almost certianly never actually work [12:44] <jnthn> benabik: .*/.+ dispatchers probably would [12:44] <bbkr> yes, i expect both methods to be invoked if signature and name matches. [12:45] <jnthn> bbkr: *only* if you used .+ or .* to ask for that. [12:45] <jnthn> bbkr: Otherwise it's an ambiguous dispatch. [12:47] <masak> it's an interesting use case. but yes, the ticket was about multi subs. [12:47] <bbkr> jnthn: ticket was about signatures in general. you're right about subs. but for methods I should be able to define multis like in my example, and it should throw "ambigous dispatch" for . [12:47] <bbkr> but not for .* [12:48] <jnthn> bbkr: Yes, we're only suggesting compile time detection for multi subs, not multi methods.
Download (untitled) / with headers
text/plain 163b
2012.10 - still NYI $ perl6 -e 'multi sub f($a) {}; multi sub f($a) {}; f(42)' Ambiguous call to 'f'; these signatures all match: :($a) :($a) in block at -e:1
Subject: [RFC] Rakudo should detect multi sub duplicates at compile time
Download (untitled) / with headers
text/plain 189b
2016.04 - still NYI. Is this feature request still deemed worthwhile? (It seems so to me, but it's one of the oldest open tickets - is there a reason it can't or shouldn't be implemented?)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org