Skip Menu |
Report information
Id: 116208
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: moritz <moritz.lenz+perl [at] gmail.com>
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Whatever-priming and thunking doesn't mix
Date: Wed, 26 Dec 2012 22:19:56 +0100
To: rakudobug [...] perl.org
From: Moritz Lenz <moritz [...] faui2k3.org>
Download (untitled) / with headers
text/plain 809b
22:07 < hoelzro> r: my $divisor = 2; say(* != $divisor && * %% $divisor); 22:07 <+p6eval> rakudo c8de2e: OUTPUT«===SORRY!===␤Error while compiling block: Error while compiling op call: Error while compiling block : Error while compiling op call: Error while compiling op if: if block expects an argument, but there's no immediate block to take it␤» 22:15 < Ayiko> r: say ((* < 5 and * > 5)(4,6)) 22:15 <+p6eval> rakudo c8de2e: OUTPUT«===SORRY!===␤Error while compiling block : Error while compiling op call: Error while compiling block : Error while compiling op call: Error while compiling op call: Error while compiling op if: if block expects an argument, but there's no immediate block to take i… I guess the mixture of whatever-priming and short-circuiting operators doesn't work out well.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Wed Dec 26 13:20:23 2012, moritz wrote: Show quoted text
> 22:07 < hoelzro> r: my $divisor = 2; say(* != $divisor && * %% $divisor); > 22:07 <+p6eval> rakudo c8de2e: OUTPUT«===SORRY!===␤Error while compiling > block: Error while compiling op call: Error while compiling block : > Error while compiling op call: Error while compiling op if: if block > expects an argument, but there's no immediate block to take it␤» > > 22:15 < Ayiko> r: say ((* < 5 and * > 5)(4,6)) > 22:15 <+p6eval> rakudo c8de2e: OUTPUT«===SORRY!===␤Error while compiling > block : Error while compiling op call: Error while compiling block : > Error while compiling op call: Error while compiling op call: Error > while compiling op if: if block expects an argument, but there's no > immediate block to take i… > > I guess the mixture of whatever-priming and short-circuiting operators > doesn't work out well.
These seems fine these days, at least on moar: 20:11 < [Coke]> r: say ((* < 5 and * > 5)(4,6)) 20:11 <+camelia> rakudo-jvm 2f7ab3: ( no output ) 20:11 <+camelia> ..rakudo-moar 2f7ab3: OUTPUT«Too many positionals passed; expected 1 argument but got 2␤ in block <unit> at /tmp/tmpfile:1␤␤» 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); 20:11 <+camelia> rakudo-{moar,jvm} 2f7ab3: OUTPUT«WhateverCode.new␤» Closable (for moar at least) with tests. -- Will "Coke" Coleda
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
bartolin_ m: say (* < 7 and * > 5)(6) camelia rakudo-moar ad062f: OUTPUT«True␤» bartolin_ is that supposed to be the same as 'say (6 < 7 and 6 > 5)'? m: say (6 < 7 and 6 > 5) camelia rakudo-moar ad062f: OUTPUT«True␤» bartolin_ m: say (* < 7 and * > 5)(7) camelia rakudo-moar ad062f: OUTPUT«True␤» FROGGS m: say (* < 7 and 7 > 5)(7) camelia rakudo-moar ab73b0: OUTPUT«Cannot find method 'postcircumfix:<( )>'␤ in block <unit> at /tmp/TTAXdxnzeL:1␤␤» FROGGS ? ahh the 'and' is not part of the code that is invoked via (7) say (* < 7 and * > 5)(7) turns into m: say (WhateverCode and * > 5)(7), so the 7 is passed to the code after the 'and' bartolin_ ahh, that explains it. it's from RT #116208 bartolin_ ... which doesn't look quite right (closable) to me FROGGS aye 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)' Too few positionals passed; expected 2 arguments but got 1 in block <unit> at -e:1 $ perl6 -e 'say ((* + 4) / (* - 4))(6,6)' 5
Download (untitled) / with headers
text/plain 1.1k
S02 <https://design.perl6.org/S02.html#line_1063> states: For any unary or binary operator (specifically, any prefix, postfix, and infix operator), if the operator has not specifically requested (via signature matching) to handle * itself, the compiler is required to translate directly to an appropriately primed closure at compile time. We call this autopriming. Most of the built-in numeric operators fall into this category. 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. But then again it also doesn't mention that the comma operator stops auto-priming, nor does it claim the list to be complete. 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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org