Establish "thunkiness" or similar terminology for operators

[2colours]

"Thunky" is mostly borrowed from Rakudo sources and surrounding discussions.

It describes the general phenomenon including short-circuiting behavior.
The usual evaluation model of an operation is that you evaluate all operands, and then pass the values into the given operator. However, some operators (such as &&, ||, ~~, andthen, xx) follow a more customized model - they only evaluate some of the operands and use their results to determine the evaluation of the other operands. Hence the name thunky - these operators have some of their operands as thunks - expressions evaluated later, in a potentially different context.

This is a fairly important property that profoundly affects the behavior of operators - topicalization, short-circuiting and xxs re-evaluation of the operand of the left are all results of the "thunkiness" of these operators. However, importantly, this "thunkiness" cannot be mimicked with any userland function, and therefore calling out to the function variant of these operators won't have the right outcome.

I still believe there should be a larger operator overhaul but this is at least something concrete and addressable.

[raiph]

I have a suggestion related to the terminology, and when and where to introduce it. But to motivate my suggestion, let me first introduce the underlying rationale.

"thunkiness" cannot be mimicked with any userland function

Raku's "spec'" design lets userland "functions" mimic "thunkiness", but A) they're a particular kind of "function" and B) the implementation of this aspect of Raku's design has ("famously", according to google's AI) ended up being punted past the first official release (6.c) and then even past the subsequent one (6.d) too. Will it arrive for 6.e? I'm hoping not (there are bigger fish to fry) but it will be a relatively small skip and hop from RakuAST landing properly and macros becoming official.

Here's a glimpse of it:

42.print || 'funky'.print and say ""; # 42

sub infix:<mimic-||-fails> ($l, $r) { $l || $r }
42.print mimic-||-fails ' not funky'.print and say ""; # 42 not funky

use experimental :macros;
macro infix:<mimic-||-"works"> ($l, $r) { quasi { {{{ $l }}} || {{{ $r }}} } }
say &infix:<mimic-||-"works"> ~~ Routine; # True

42.print mimic-||-"works" 'funky!'.print and say ""; # 42

You could of course argue that macros are not "functions". And in the sense that Raku terminology uses the word "routines" instead of "functions" as its generic term for "functions", you'd be right. That said, their declaration and signature syntax is identical to that for sub declarations, just with macro instead of sub.

You could also argue that macros aren't implemented. And you'd be right. (There's still a reason though to take them into consideration, as I get to later.)

Finally, you could argue that thunks aren't functions. But, to quote Wikipedia:

In computer programming, a thunk is a subroutine ...

---

I'm not sure whether Raku's macro design allows userland macros to introduce "thunkiness" on the left of a given userland macro token/identifier.

That said, I don't think any of Raku's uses of "thunkiness" for its current built ins do that.

In addition, one of the many reasons why macros have awaited production implementation for so long is that anything macros can do, slangs can do ("better", to complete the song in my head, though that ignores the fact that creating and using a slang is sometimes like using a sledgehammer to crack a nut in contrast to macros being about as complex/simple as nut crackers -- not quite as simple as a plain function, but often close).

---

OK, with that background in place, here's my first suggestion. If you must introduce a new term, I suggest it's introduced in the doc for macros. Of course, that hasn't been written yet, so there's an interim concern of where to put it, but I currently think the macros doc is likely to be a better place to host the topic than any other, given that:

• Exactly the same topic, namely when operands get evaluated, and what controls that timing, will be a big topic in the macro doc;

• It is a topic that can throw people unless it's situated within exactly that kind of discussion. So linking from the operators page to this aspect of macros will make sense.

(That said, I could also see this topic being a fragment within a broader page discussing "Evaluation of operands", or an even broader page, "Evaluation order", or even broader, just "Evaluation". Maybe it's a fragment that's transcluded as needed in various pages -- "Operators", "Macros", "Compilation stages", etc.)

---

One final small point, one such that I don't care whether or not it is taken into account, but which I will of course spend the longest part of this comment covering, because it's borderline bikeshedding.

Some folk struggle to understand "thunkiness", despite it really being very simple. In my experience, a big part of the problem is the weird name ("thunk") which leaves someone encountering it stumbling to orient their mind to what it is.

To again quote Wikipedia (from the page I quoted earlier):

The term originated as a whimsical irregular form of the verb think.

(The page goes on to explain how that in turn was grounded in Algol terminology that used the term "thought" as part of an attempt to deliberately avoid a vastly more complicated concept and word: "function"!)

A technique I find sometimes works (and which the inventor of "thunk" may well have been applying) is to eschew "correct" terminology if it's not especially familiar among neophyte devs, especially if there's a friendly alternative that not only does not contradict the technically more "correct" terminology but is also reminiscent of it in some mnemonic way, while nevertheless blunting the sense that a given topic has a "complicated" name because the topic itself is "complicated".

(This is exactly what Algol was trying to do, with the inventor of "thunk" building on that. At that time, most people knew what "thoughts" were, but not "functions", so the Algol folk ran with "thoughts" rather than "functions" or "subroutines". Ah, how time flies.)

Anyway, with that technique in mind, the name "funky" popped into my head as a way to go in the reverse direction from where things were at in the 1960s.

First, the term "funky" is mnemonically reminiscent of both "functions" and "thunkiness".

Second, just as importantly, I think it will sound (for most Native English readers at least) kinda fun and, well, funky. That's pretty much exactly what I think is the right pitch. After all, thunkiness isn't especially complex, just a little funky.

(I grant there's always the Raku design principle of "You think that's cute today...", but in this case, I'd be very surprised if I decided there was a downside to using the term "funky" much before I began reviewing my life while hanging out in hell.)

[2colours]

You could of course argue that macros are not "functions".

I do argue that, and I think that's quite important - at least as important as "macros aren't available". If macros existed and "thunky" operators were implemented with macros, they would still deserve to be a separate category, even by the terms of "operators implemented as macros".

Whether the name should be "thunky" or something completely different - recommendations welcome, for sure! - is up to discussion.

I would like to see actionable suggestions that don't explode the scope of the issue. I would like to see pages about the evaluation and the evaluation of operators within - but I know I'm not up for writing them myself at the moment. If you suggest something like this, please do volunteer for it, too.

In other cases, I think it is an important and impactful property of operators how (and when) they evaluate their operands, whatever name we are going to give the phenomenon, and whatever way they will be implemented. This is what I would like to stick with, for the topic of this issue.