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
Whatever-priming and thunking doesn't mix #3008
Comments
From @moritz22:07 < hoelzro> r: my $divisor = 2; say(* != $divisor && * %% $divisor); 22:15 < Ayiko> r: say ((* < 5 and * > 5)(4,6)) I guess the mixture of whatever-priming and short-circuiting operators |
From @cokeOn Wed Dec 26 13:20:23 2012, moritz wrote:
These seems fine these days, at least on moar: 20:11 < [Coke]> r: say ((* < 5 and * > 5)(4,6)) Since the whatever code there has a single parameter, the *, we can't pass two in. 20:11 < [Coke]> r: my $divisor = 2; say(* != $divisor && * %% $divisor); Closable (for moar at least) with tests. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @usev6bartolin_ m: say (* < 7 and * > 5)(6) AFAIU whatever-priming still does not work correctly with short-circuiting operators. Shouldn't the example code only run with 2 arguments -- like the following? $ perl6 -e 'say ((* + 4) / (* - 4))(6)' $ perl6 -e 'say ((* + 4) / (* - 4))(6,6)' |
1 similar comment
From @usev6bartolin_ m: say (* < 7 and * > 5)(6) AFAIU whatever-priming still does not work correctly with short-circuiting operators. Shouldn't the example code only run with 2 arguments -- like the following? $ perl6 -e 'say ((* + 4) / (* - 4))(6)' $ perl6 -e 'say ((* + 4) / (* - 4))(6,6)' |
From @smlsS02 <https://design.perl6.org/S02.html#line_1063> states: For any unary or binary operator (specifically, any prefix, Then further down, it lists these operators as ones that *don't* participate in autopriming: xx It doesn't mention `|| && // and or` in that list. Interestingly, the Z and X operators do autoprime in Rakudo even though they have much looser precedence than the comma: say ( 1, 2, 3 Z * )(<a b c>); # ((1 a) (2 b) (3 c)) Is there a reason for `|| && // and or` not to do the same (other than that they'd loose their short-circuiting behavior)? I think this needs a @LARRY decision, and possibly an investigation into what would break if this was changed. |
Migrated from rt.perl.org#116208 (status was 'open')
Searchable as RT116208$
The text was updated successfully, but these errors were encountered: