Traps candidate? Sinkage of maps

[zoffixznet]

Just mapping stuff in sink context may make people think it's perfectly fine to do it all the time:

m: <foo bar ber>.map: *.say
rakudo-moar 334b87226: OUTPUT: «foo␤bar␤ber␤»

However, if you nest another Seq inside (e.g. another map), that Seq just becomes an item inside the first Seq and so isn't sunk and the map isn't evaluated:

m: <foo bar ber>.map: *.say
rakudo-moar 334b87226: OUTPUT: «foo␤bar␤ber␤»
m: <foo bar ber>.map: *.comb.map: *.say
rakudo-moar 334b87226: OUTPUT: «»

[JJ]

See also #732 #1309 In general, sinking needs a better documentation.

[AlexDaniel]

I think adc5f09 doesn't explain why it happens.

[JJ]

In this case, I'm not 100% it's an effect of sinkage. In fact, say returns True. You would be sinking a list of Trues in the first case, and the same would apply to the second case. If you take a single element of the innermost map and sink it, it will still output something. Expected result here would be printing of the letters of every element, and a list of lists of Trues that is sunk.

[JJ]

@AlexDaniel you caught me writing the explanation above. I really don't know why it happens. I have avoided referring to sink and included a workaround. That's good enough for the trap documentation, at least for me. If you've got a better theory, just let me know...

[JJ]

I have posted this in StackOverflow to clarify what's going on in the "normal" case, which I think it shouldn't work.

[AlexDaniel]

The answers on StackOverflow are nice, the current documentation is not. Reopening :)

[JJ]

That's precisely why I've asked that and linked the question...