Pm (>):
> S03 has:
>
> For functions deduced when there is only one value on the left,
> the final value is used to determine whether *.succ or *.pred is
> more appropriate. The two values are compared with C<cmp> to
> determine the direction of the progression.
>
> Rakudo evaluates C< "perl" cmp { ... } > as C<Order::Decrease>,
> therefore it's using the .pred/decreasing progression.
Aye. That's clearly to spec.
> So, one of the following:
> a) &infix:<cmp> should produce a different result for Str vs Code
> (if so, what?),
&infix:<cmp> is consistent the way it is, but it's a consistency that
surprises people. (Basically, comparing across incompatible is
impossible.) Adding an exception for Str vs Code feels wrong, and is the
opposite of what &infix:<cmp> would need to be saner.
> b) &infix:<...> should assume .succ if the final value is a Code
object,
This alternative makes sense to me. It's similar to how &infix:<...>
assumes .succ in this case: '"perl" ... *'
> c) Rakudo is correct, or
No. :)
> d) Some other spec clarification or change needs to be made.
I'm very satisfied with how the sequence spec has turned out. It's
stable and in some kind of sweet spot. I don't imagine it needs an
overhaul of any kind, actually. But the way this particular case worked
surprised me as a user.
