From @moritz

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.

From @coke

On Wed Dec 26 13​:20​:23 2012, moritz wrote​:

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

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

From @usev6

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

From @smls

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.