From @pmichaud

The .infinite method on Any is designed to return one of three values​:
  True - known to be infinite
  False - known to be finite
  Nil - finite-ness not yet known or determined

The "Nil" (undefined) result is often provided for lists that are being evaluated lazily... rather than force eager evaluation of the list, the list can simply return an undefined value meaning "I don't know yet if I'm finite or infinite".

With that in mind, something about splicing Captures isn't properly honoring .infinite. Here's an illustration​:

  03​:08 <pmichaud> r​: sub g(*@​v) { say @​v.infinite; }; g(4..*); # correct
  03​:08 <camelia> rakudo-{parrot,moar} fd017a​: OUTPUT«True␤»
  03​:08 <pmichaud> r​: sub g(*@​v) { say @​v.infinite; }; g('a',4..*); # correct
  03​:08 <camelia> rakudo-{parrot,moar} fd017a​: OUTPUT«Nil␤»
  03​:08 <pmichaud> r​: sub g(*@​v) { say @​v.infinite; }; g(|('a',4..*)); # correct
  03​:08 <camelia> rakudo-{parrot,moar} fd017a​: OUTPUT«Nil␤»
  03​:08 <pmichaud> r​: sub g(*@​v) { say @​v.infinite; }; g(|(4..*)); # incorrect
  03​:08 <camelia> rakudo-{parrot,moar} fd017a​: OUTPUT«False␤»

The last case shows the problem -- when a Capture has a single infinite argument, splicing it into the slurpy paramete loses its finite nature. Either "True" or "Nil" would be acceptable for this last answer, but "False" is the absolute wrong result.

This is ultimately the cause of the bug described in RT #​118867 dealing with the [max] reduction operator.

Pm

From @pmichaud

After discussion with jnthn tonight after APW '14.

Ignore everything above -- the bug is in fact somewhat different.

The short answer is that spliced arguments need to be eagerly evaluated. Currently they're only partially evaluated using .gimme(*), which may be insufficient for argument passing or dispatch.

The result of a call like g(|(1..*)) should be either an infinite hang (generating an infinite list) or an exception generated as a result of attempting to eagerly evaluate an infinite Iterable.

(Currently Rakudo neither hangs nor throws an exception on (1..*).eager, which is a separate bug.)

Pm

From @niner

The result of a call like g(|(1..*)) should be either an infinite
hang (generating an infinite list) or an exception generated as a
result of attempting to eagerly evaluate an infinite Iterable.

g(|(1..*)) does indeed hang, now that the GLR is merged.

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

From @niner

closed

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