On Sun, May 30, 2021 at 10:18:13PM -0400, yary wrote:
: This came up in today's Raku study group (my own golfing-)
:
: > ? (any(4,3) ~~ 3)
: True
: > ? (3 ~~ any(4,3))
: True
: > given any(4,3) { when 3 {say '3'}; say 'nope'}
: nope
: > given 3 { when any(4,3) {say '3'}; say 'nope'}
: 3
: > given any(4,3) { say .raku }
: any(4, 3)
:
: why does Raku say 'nope' for the example *"**given any(4,3) { when 3 {say
: '3'}; say 'nope'}*"
:
: Since this expression is true *? (any(4,3) ~~ 3)*
: I expected the "*given 4|3*" to also match "*when 3*"
I think both of these should be returning False. In general, the left side of
~~ should
not be auto-threading, or we revert to the suboptimal Perl semantics of
smartmatching.
The reason we broke the symmetry of smartmatch is so that we can optimize based
on
the type of the right-hand argument, and allowing auto-threading of the other
argument
prevents that. Note that in the switch structure above, "when 3" is supposed
to be
optimizable to a jump table, but how do you calculate a jump from a junction?
So we
biased smartmatching in the direction of coercion-first semantics rather early
on
(though, alas, not early enough to prevent Perl adoption of the earlier design).
In any case, the documentation says ~~ is defined underlyingly by .ACCEPTS, and
for a Numeric pattern, that says:
multi method ACCEPTS(Numeric:D: $other)
Returns True if $other can be coerced to Numeric and is numerically equal
to the invocant
(or both evaluate to NaN).
And I'd be awfully surprised if any(4,3) can be coerced to Numeric in any
meaningful way...
Perhaps this should be documented as a trap for people coming from Perl, if it
isn't already.
Larry
