On Tue Oct 16 09:18:27 2012, [email protected] 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
