m_turner has asked for the wisdom of the Perl Monks concerning the following question:

After a long absence from Perl (alas, Java pays the bills), I was looking at getting back to competency with perl 6 and looking at a "try writing an idiomatic blackjack program." The 1 or 11 nature of the ace seems like a perfect use for a Junction. To make sure I knew how to use a Junction and sum with it, I started with a list of numbers and worked with the "most people write it this way" of https://docs.perl6.org/type/Array#(List)_routine_reduce :
my @list = (1, 2, 3); my $sum = [+] @list; say $sum;
And that worked. Adding a Junction to this:
my @list = (1, 2|3, 4); my $sum = [+] @list; say $sum;
And that spat out an error: "Type check failed in assignment to $sum; expected Numeric but got Junction (any(3, 4))"

Switching this code to another form of list summation

my @list = (1, 2|3, 4); my $sum = @list.reduce(*+*); say $sum;
That works fine.

This mismatch of expectations and errors also occurs with $sum = @list.sum; when there is a Junction in the list. So, what I'm wondering is "what is the difference between these invocations?" I suspect its something with the type system that I haven't wrapped my head around yet and that it is working as expected.

It's also quite possible that I'm introducing an XY problem in to this and that I shouldn't be doing it this way in the first place - and if that's the case, a pointer off to the more idiomatic way of dealing with what looks to be a good fit for the ace = 1|11 state would be appreciated.

Replies are listed 'Best First'.
Re: [+] on a list... with a Junction
by Zoffix (Acolyte) on Nov 23, 2016 at 11:14 UTC
      Thank you for the mention and the bug fix. I was waiting to get back to my computer to write up the bug report (something, something, work computer, personal email).

      I'm not yet familiar enough with the code base to be certain, but I wonder if that change will resolve the tangential bug(?) of say [+] (1, 2|3, 4); (does it do magic to map [+] to .sum?)

        Yeah, that is fixed as well. The [+] metaop is special-cased to become sum() since it's pretty common and we have other optimizations for .sum, like the one on Range objects for example:

        say sum 1..999999999999999999999999999; # 499999999999999999999999999500000000000000000000000000
A reply falls below the community's threshold of quality. You may see it by logging in.