It's not the decorate-sort-undecorate of a by-the-book ST, but it's a direct equivalent which retains the ST's generality and efficiency and substantially improves on its elegance.
To understand how the P6 design retains full ST capability, follow my attempt to P6ify your example thru two versions, the first not ST equivalent, the second equivalent:
enum days <mo tu we th fr sa su>; enum months <jan feb mar apr may jun jul aug sep oct nov dec>; my $noon = DateTime.new(now) .truncated-to(day) .delta(12, hours); my @dates = $noon, *.delta(1, day), ... *; my @ordered = sort { ~days($^a.day-of-week - 1) cmp ~days($^b.day-of-week - 1) || ~months($^b.month - 1) cmp ~months($^a.month - 1) } ], @dates[^365];
Some may quibble with the jump from the +* construct to a { ... } closure. But +* in term position is just sugar for a (one arg) closure (which as an arg to sort is assumed to be a "key extractor" closure).
Some may quibble with the jump from a one arg "key extractor" closure to a two arg P5 style "comparator" closure. But P6 uses the one arg closure to do the same thing for both args ($a and $b in P5) in an automatically constructed comparator closure, and assumes use of cmp for comparison. So, no need for an explicit two arg "comparator" closure unless you really want one.
Update I had intended that folk would read this comment as a whole, including what comes next, but I think some stopped at the above. The above works in current Rakudo, reads pretty cleanly, and is fully general functionally, but is not ST equivalent in at least the sense that it doesn't cache the keys. The following reads cleanly, does cache the keys, and is fully general -- but does not work in current Rakudo.
enum days <<:mo(1) tu we th fr sa su>>; enum months <<:jan(1) feb mar apr may jun jul aug sep oct nov dec>>; my $noon = DateTime.new(now).truncated-to(day).delta(12, hours); my @dates = $noon, *.delta(1, day), ... *; my @ordered = sort [ { ~days(.day-of-week) }, { ~months(.month) } is descending ], @dates[^365];
Update Let's add some commentary to try make the ST equivalency pop...
Those two closures ({ ~days(.day-of-week) }, { ~months(.month) }) are key extractor closures. They correspond to the two calls in the P5 original:
substr(scalar localtime($_),0,3), substr(scalar localtime($_),+5,3)
Just as one can have arbitrary before maps with P5 ST, the P6 sort builtin design supports any number of arbitrary key extractor closures. P6 then automatically generates two comparator closures, and runs the first comparison to see if it sorts between a given pair of items, and if it doesn't, runs the next comparison. This corresponds to the P5:
$a->[1] cmp $b->[1] || $b->[2] cmp $a->[2]
(The descending aspect of the second cmp expression in the P5 comparator closure is covered by the is descending trait on the second closure in the P6 code.)
In reply to Re^2: sort +*, @array
by raiph
in thread sort +*, @array
by raiph
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |