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

Ordering of multis doesn't tie-break in Rakudo #2894

Closed
p6rt opened this issue Sep 13, 2012 · 5 comments
Closed

Ordering of multis doesn't tie-break in Rakudo #2894

p6rt opened this issue Sep 13, 2012 · 5 comments

Comments

@p6rt
Copy link

p6rt commented Sep 13, 2012

Migrated from rt.perl.org#114886 (status was 'resolved')

Searchable as RT114886$

@p6rt
Copy link
Author

p6rt commented Sep 13, 2012

From @masak

<TimToady> in http://rosettacode.org/wiki/FizzBuzz#Perl_6 the second
solution should not require 'is default' according to S12​:1210
<TimToady> masak​: ^ rakudobug
<masak> TimToady​: are you able to demonstrate it golfed on p6eval? that helps.
<TimToady> r​: multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' };
multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' }; multi sub
fizzbuzz(Int $ where * %% 3) { 'Fizz' }; multi sub fizzbuzz(Int
$number) { $number }; (1 .. 100)».&fizzbuzz.join("\n").say;
<p6eval> rakudo 100727​: OUTPUT«Ambiguous call to 'fizzbuzz'; [...]
<TimToady> :)
<TimToady> I golfed it by removing some newlines :P
<jnthn> That's because I disagree with the spec so deliberately didn't
follow it. :)
<jnthn> I think you *shouold* need "is default" rather than relying on ordering.
<TimToady> I don't
* moritz also finds that spec highly dubious
<jnthn> Because when you've multis that are imported, ordering is dodgy.
<TimToady> and the paragraph in question gives the rationale
<jnthn> TimToady​: It seems cute today. :)
<masak> I think I agree with jnthn, too. but a rakudobug is a rakudobug.
<jnthn> I have a bad feeling it'll be less cute in the future.
* masak submits rakudobug
<TimToady> I think it's a necessity to avoid forcing people into using
'is default' where that would be even boguser
<jnthn> When is it boguser?
<TimToady> most of the time
* jnthn doesn't see how it's bogus in this case, fwiw.
<moritz> and, when isn't it bogus?
<jnthn> Source code ordering just feels to me like a poor tie-breaker
of last resort, that's all.
<TimToady> so we substitute a poorer one
<jnthn> I don't find being explicit about what you want poorer. I
guess I don't see the real issue yet.
<[Coke]> ordering gives you a rank, is default gives you "the best" ?
<[Coke]> I can't imagine doing something that crazy with multis and
expecting it to work either way, though.
<jnthn> It only comes up when you have constraints that are not
mutually exclusive.
<[Coke]> Seems like making it clear from the signature would be best.
<[Coke]> jnthn​: at which point a sane person would have a multi with a
switch in it.
<jnthn> [Coke]​: That is one way to look at it :)
<jnthn> I can see the attraction to using multis here, though.
<TimToady> the upside is much bigger than the downside, in my estimation
<jnthn> But yeah, the given/when feels more robust.
<moritz> one can still do (Int $ where { $_ %% 5 && $_ % 3})
<TimToady> one can be as unclear as one likes, but lack of clarity is
not what we're optimizing for here

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

From @jnthn

On Thu Sep 13 11​:08​:56 2012, masak wrote​:

<TimToady> in http://rosettacode.org/wiki/FizzBuzz#Perl_6 the second
solution should not require 'is default' according to S12​:1210
<TimToady> masak​: ^ rakudobug
<masak> TimToady​: are you able to demonstrate it golfed on p6eval?
that helps.
<TimToady> r​: multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' };
multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' }; multi sub
fizzbuzz(Int $ where * %% 3) { 'Fizz' }; multi sub fizzbuzz(Int
$number) { $number }; (1 .. 100)�.&fizzbuzz.join("\n").say;
<p6eval> rakudo 100727​: OUTPUT�Ambiguous call to 'fizzbuzz'; [...]
<TimToady> :)
<TimToady> I golfed it by removing some newlines :P
<jnthn> That's because I disagree with the spec so deliberately didn't
follow it. :)
<jnthn> I think you *shouold* need "is default" rather than relying on
ordering.
<TimToady> I don't
* moritz also finds that spec highly dubious
<jnthn> Because when you've multis that are imported, ordering is
dodgy.
<TimToady> and the paragraph in question gives the rationale
<jnthn> TimToady​: It seems cute today. :)
<masak> I think I agree with jnthn, too. but a rakudobug is a
rakudobug.
<jnthn> I have a bad feeling it'll be less cute in the future.
* masak submits rakudobug
<TimToady> I think it's a necessity to avoid forcing people into using
'is default' where that would be even boguser
<jnthn> When is it boguser?
<TimToady> most of the time
* jnthn doesn't see how it's bogus in this case, fwiw.
<moritz> and, when isn't it bogus?
<jnthn> Source code ordering just feels to me like a poor tie-breaker
of last resort, that's all.
<TimToady> so we substitute a poorer one
<jnthn> I don't find being explicit about what you want poorer. I
guess I don't see the real issue yet.
<[Coke]> ordering gives you a rank, is default gives you "the best" ?
<[Coke]> I can't imagine doing something that crazy with multis and
expecting it to work either way, though.
<jnthn> It only comes up when you have constraints that are not
mutually exclusive.
<[Coke]> Seems like making it clear from the signature would be best.
<[Coke]> jnthn​: at which point a sane person would have a multi with a
switch in it.
<jnthn> [Coke]​: That is one way to look at it :)
<jnthn> I can see the attraction to using multis here, though.
<TimToady> the upside is much bigger than the downside, in my
estimation
<jnthn> But yeah, the given/when feels more robust.
<moritz> one can still do (Int $ where { $_ %% 5 && $_ % 3})
<TimToady> one can be as unclear as one likes, but lack of clarity is
not what we're optimizing for here

Fixing the other issue (missing map) at the end of this code​:

multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' }; multi sub
fizzbuzz(Int $ where * %% 5) { 'Buzz' }; multi sub fizzbuzz(Int $ where
* %% 3) { 'Fizz' }; multi sub fizzbuzz(Int $number) { $number }; (1 ..
100).map(&fizzbuzz).join("\n").say;

This now works fine in latest Rakudo. Tagging testneeded.

/jnthn

@p6rt
Copy link
Author

p6rt commented Oct 16, 2012

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

@p6rt
Copy link
Author

p6rt commented Nov 14, 2012

From @coke

On Tue Oct 16 09​:18​:27 2012, jnthn@​jnthn.net wrote​:

On Thu Sep 13 11​:08​:56 2012, masak wrote​:

<TimToady> in http://rosettacode.org/wiki/FizzBuzz#Perl_6 the second
solution should not require 'is default' according to S12​:1210
<TimToady> masak​: ^ rakudobug
<masak> TimToady​: are you able to demonstrate it golfed on p6eval?
that helps.
<TimToady> r​: multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' };
multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' }; multi sub
fizzbuzz(Int $ where * %% 3) { 'Fizz' }; multi sub fizzbuzz(Int
$number) { $number }; (1 .. 100)�.&fizzbuzz.join("\n").say;
<p6eval> rakudo 100727​: OUTPUT�Ambiguous call to 'fizzbuzz'; [...]
<TimToady> :)
<TimToady> I golfed it by removing some newlines :P
<jnthn> That's because I disagree with the spec so deliberately didn't
follow it. :)
<jnthn> I think you *shouold* need "is default" rather than relying on
ordering.
<TimToady> I don't
* moritz also finds that spec highly dubious
<jnthn> Because when you've multis that are imported, ordering is
dodgy.
<TimToady> and the paragraph in question gives the rationale
<jnthn> TimToady​: It seems cute today. :)
<masak> I think I agree with jnthn, too. but a rakudobug is a
rakudobug.
<jnthn> I have a bad feeling it'll be less cute in the future.
* masak submits rakudobug
<TimToady> I think it's a necessity to avoid forcing people into using
'is default' where that would be even boguser
<jnthn> When is it boguser?
<TimToady> most of the time
* jnthn doesn't see how it's bogus in this case, fwiw.
<moritz> and, when isn't it bogus?
<jnthn> Source code ordering just feels to me like a poor tie-breaker
of last resort, that's all.
<TimToady> so we substitute a poorer one
<jnthn> I don't find being explicit about what you want poorer. I
guess I don't see the real issue yet.
<[Coke]> ordering gives you a rank, is default gives you "the best" ?
<[Coke]> I can't imagine doing something that crazy with multis and
expecting it to work either way, though.
<jnthn> It only comes up when you have constraints that are not
mutually exclusive.
<[Coke]> Seems like making it clear from the signature would be best.
<[Coke]> jnthn​: at which point a sane person would have a multi with a
switch in it.
<jnthn> [Coke]​: That is one way to look at it :)
<jnthn> I can see the attraction to using multis here, though.
<TimToady> the upside is much bigger than the downside, in my
estimation
<jnthn> But yeah, the given/when feels more robust.
<moritz> one can still do (Int $ where { $_ %% 5 && $_ % 3})
<TimToady> one can be as unclear as one likes, but lack of clarity is
not what we're optimizing for here

Fixing the other issue (missing map) at the end of this code​:

multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' }; multi sub
fizzbuzz(Int $ where * %% 5) { 'Buzz' }; multi sub fizzbuzz(Int $ where
* %% 3) { 'Fizz' }; multi sub fizzbuzz(Int $number) { $number }; (1 ..
100).map(&fizzbuzz).join("\n").say;

This now works fine in latest Rakudo. Tagging testneeded.

/jnthn

Test added to S06-multi/syntax.t.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Nov 14, 2012

@coke - Status changed from 'open' to 'resolved'

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

No branches or pull requests

1 participant