Navigation Menu

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

Disable textual ordering as a tie-breaker in multi dispatch #1286

Closed
tisonkun opened this issue Nov 30, 2017 · 2 comments
Closed

Disable textual ordering as a tie-breaker in multi dispatch #1286

tisonkun opened this issue Nov 30, 2017 · 2 comments

Comments

@tisonkun
Copy link
Contributor

So here we are.

At first, in the case below, we assume when users define 'ambiguous' candidates, that is a mistake.

multi sub f(Int \a, Any \b) { }
multi sub f(Any \a, Int \b) { }
f(42, 42) # ambiguous

However, we then trust our users again, assuming they know textual ordering matters if tie-breaker applied.

multi sub f(Int \a where * > 0, Any \b) { }
multi sub f(Any \a, Int \b where * < 100) { }
f(42, 42) # the former is taken

Here is where users rarely arrive(really? around me people write code with a great variety of fantasies), but it shows what perl6 thinks of perl6 programmers.

Based on https://irclog.perlgeek.de/perl6/2017-11-30#i_15512831 , I arbitrarily put forward "Disable textual ordering as a tie-breaker in multi dispatch". The opposite is OK, that is enabling textual ordering even when users didn't use other tie-breaker, that means we believe perl6 programmers know what they do and be responsible for that, IMO.

@zoffixznet
Copy link
Contributor

zoffixznet commented Nov 30, 2017

My vote is to follow the path of least resistance (and least user impact) and leave it as is. We're into our third year of claiming we're a stable language, so some things we'll have to accept and learn to live with.

Disabling isn't great. You'd have to try ALL of the available multies with wheres each time, which would be a performance impact and also would introduce a lot of unpredictability into programs. If the programmer didn't foresee a possible intersection where two of the wheres return True, they'll have a range of input for their program that simply crashes. That type of stuff is a lot harder to think about than ordering of the candidates in the source.

The opposite is OK, that is enabling textual ordering even when users didn't use other tie-breaker

I'm not 100% sure what you mean. Do you mean removing the ambiguity detection and just using the source ordering for candidates where we can tell with 100% certainty there'd be an ambiguity with 100% of input (something that isn't the case with where clauses).

@tisonkun
Copy link
Contributor Author

That type of stuff is a lot harder to think about than ordering of the candidates in the source.

Agree with this. The most confusing point is why we disable textual ordering sometime. Now I approve of that we can die for ambiguous because there is "where we can tell with 100% certainty there'd be an ambiguity with 100% of input"

We're into our third year of claiming we're a stable language

Wish it being stable.

OK, I will attempt to accept that it is how perl6 works and learn it.

I'll close this issue a little later, if no one has other thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants