Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rakudo should detect multi sub duplicates at compile time #1455

Closed
p6rt opened this issue Dec 22, 2009 · 14 comments
Closed

Rakudo should detect multi sub duplicates at compile time #1455

p6rt opened this issue Dec 22, 2009 · 14 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Dec 22, 2009

Migrated from rt.perl.org#71536 (status was 'open')

Searchable as RT71536$

@p6rt
Copy link
Author

p6rt commented Dec 22, 2009

From @masak

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.

@p6rt
Copy link
Author

p6rt commented Dec 22, 2009

From @moritz

Carl MXXsak (via RT) wrote​:

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?

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

@p6rt
Copy link
Author

p6rt commented Dec 22, 2009

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Sep 13, 2011

From @bbkr

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.

@p6rt
Copy link
Author

p6rt commented Nov 15, 2012

From @bbkr

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

@p6rt
Copy link
Author

p6rt commented May 21, 2016

From @smls

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?)

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
@JJ
Copy link

JJ commented May 6, 2020

2020.05 is pretty much the same.

Ambiguous call to 'f(Int)'; these signatures all match:
:($a)
:($a)
  in block <unit> at -e line 1

It's probably calling for a problem solving ticket...

@masak
Copy link

masak commented May 7, 2020

It's probably calling for a problem solving ticket...

Yes, probably.

To me, it falls in the same category as other "oopsie" mistakes that we could detect at compile time:

  • use of a variable without declaring it
  • declaring an (only) sub and then calling it with impossible arguments
  • putting a return on the top level where there's no routine to return from

All these (and the current issue) share the following sentiment: "this would definitely fail at runtime (as soon as you hit that line), so we fail you now, at comile time, because we're nice that way and we don't want you to waste an iteration cycle that will surely fail".

@JJ
Copy link

JJ commented May 16, 2021

The related problem-solving ticket was closed, this is still an issue. Probably something to be solved in the RakuAST branch?

@JJ
Copy link

JJ commented Nov 3, 2023

This is the very first issue still open in the old issue tracker. Is there any attempt to solve it using RakuAST?

@lizmat
Copy link
Contributor

lizmat commented Nov 3, 2023

Not yet, perhaps create a new issue for this and mark it with RakuAST ?

@JJ
Copy link

JJ commented Nov 3, 2023

I'm not even sure it could be solved that way...

@lizmat
Copy link
Contributor

lizmat commented Nov 3, 2023

Pretty sure it can :-)

@JJ
Copy link

JJ commented Nov 3, 2023

Closing in favor of rakudo/rakudo#5455

@JJ JJ closed this as not planned Won't fix, can't repro, duplicate, stale Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

4 participants