Whatever-priming and smartmatches

[2colours]

Whatever-priming is what we used to call whatever-currying for a long time. (Fun fact: when this was changed, I specifically warned about the visibility of the change in terminology. Apparently I forgot about the change itself since then...)

It doesn't have a separate page but it's described in some detail at the reference of Whatever. This contains a not-so-exhaustive list of operators that don't prime with the whatever star - in particular, "thunky" operators (operators that somehow mimic lazy evaluation with some of their operands, effectively making the operand an expression to evaluate rather than a value) such as && or andthen usually don't prime and they aren't mentioned here.

Another interesting case would be the smartmatch operator ~~. It's not discussed from this angle. The behavior seems to be basically the opposite of ..: the whatever star primes but a WhateverCode cannot be primed further. A bunch of examples.

dd 1 ~~ *; # WhateverCode.new
dd * ~~ 1; # WhateverCode.new
dd * + 1 ~~ 2; # False - additionally warns that "WhateverCode on LHS of smart-match does not curry[sic!] the smart-match expression."
dd 2 ~~ * + 1; # True(!)

I swear, I originally just wanted to show and illustrate something documented, and as I'm writing the post, we bump into various issues again...

• the warning uses the obsolete terminology ("curry" as opposed to "prime")
• the warning implies (I didn't copy the next line of the warning: it actually outright suggests) that a WhateverCode instance would prime on the right handside and it apparently doesn't.

I think it's worth talking about why the right handside version returns True specifically. I think ultimately this is a natural consequence of the WhateverCode not currying and the usual behavior for any Code on the right handside: 2 ~~ {$_ + 1} produces the same result. Another annoyance here: the oldest version one can just download and extract with rakubrew, Rakudo 2019.11, produces 3 for 2 ~~ {$_ + 1} - which could very well be a known regression that got fixed since. Reminds me of this regression-feature that got "fixed".
Anyway, for Code, we basically make a call to the function - usually with the topic supplied as the only argument and this is essentially the same in the specific case of WhateverCode as well, with different internals. The smartmatch is responsible for coercing this into a Bool value - I'm not sure how version 2019.11 could even evade this but it doesn't matter now.

The site does discuss smartmatch and whatever-priming in some context, down below, starting with the paragraph:

A stored * will also result in the generation of a WhateverCode in the specific case of smartmatch. Note that this is not actually the stored * which is being primed, but rather the * on the left-hand side.

(The code snippet in the docs can actually be taken as an example of the previously described smartmatch behavior of functions on the right handside, if we imagine &find-constraint as something returning a (single-parameter) function.)

The two sentences seemingly contradict and I see no resolution of this contradiction - apart from "the second sentence is true, the first sentence is false". They are two commits one after the other, dating back before "Christmas", written by John Haltiwanger. What really gets me is how the same person could write these things at basically the same time when the sentences contradict in a very important way: there are no signs the smartmatch would have any unusual non-syntactic behavior which would otherwise make it completely unlike any other behavior of whatever-priming! This is something that would be good to clarify.

As I was preparing this post, I also noticed a traps entry related to this topic. This is were the real bad news arrive...

The entry got originally added as per Raku/doc#1603. I think the original behavior is a bit peculiar to begin with but anyway, now there is a trap entry and even a warning, similar to the one that I showed before. Now, there really is a fractal of problems:

• the theoretical problem about the suggestion: smartmatch is not symmetric. $x.Int ~~ 2 is not the same as 2 ~~ $x.Int to begin with. If $x can be Int, $x.Int will suddenly accept everything that is of type Int (including its subtypes, of course). (Beware: if you write 2 ~~ .Int, that will always be True because it actually evaluates 2 ~~ 2.Int!)
• *.Int ~~ 2 does not equal 2.ACCEPTS(*.Int) but as we have seen, 2.ACCEPTS(*.Int).Bool. Here, this doesn't make a lot of difference because 2.ACCEPTS(*.Int) has always(?) returned False anyway
• 2 ~~ *.Int does not equal *.Int.ACCEPTS(2) or even *.Int.ACCEPTS(2).Bool - it equals ((*.Int)).ACCEPTS(2).Bool! As we have seen earlier, Rakudo 2019.11 somehow skips the Bool coercion and therefore it invokes *.Int with 2, resulting 2. Therefore it seems like the suggestion works with Rakudo 2019.11 but it actually works for the wrong reason: the matcher is actually a constant 2, not a Callable, and it's greps internal reliance on smartmatching that makes the result the same. Since the Bool coercion does happen in Rakudo 2025.03 (and probably for some time by now), the suggestion will fail with the same error as the original code that suggested you to use it.

Great. So ultimately, both the docs and the compiler suggest you to do something that doesn't work just as much. Somebody could bisect it to see if WhateverCode ever "curried" (in modern terms: primed - perhaps the terminology of the compiler should also be updated) on the right handside.