Sounds like fun! I’ve recently added prepend reversed first list to second list (Z31580) as a “primitive” reversal function. It scales reasonably well, but can we look forward to significant improvement with V2 tail-call optimisation? One thing I noticed is that the type for the result list is de-referenced to a full type object on recursion, which seems undesirable.

Reversing 49 forms of être.

Hopefully! There are some aspects of tail recursion that will require additional work (namely, an extra abstraction to track whether an arbitrary set of resolution operations from one Z7 leads to another Z7), but for the uses of Z812 in particular, I suspect we'll be able to get some improvements. The type de-referencing will hopefully be fixed in V2, as well. I'm now going to make liberal use of your function as a test case, hehe.

In T417018#11607178, @GrounderUK wrote:

Sounds like fun! I’ve recently added prepend reversed first list to second list (Z31580) as a “primitive” reversal function. It scales reasonably well, but can we look forward to significant improvement with V2 tail-call optimisation? One thing I noticed is that the type for the result list is de-referenced to a full type object on recursion, which seems undesirable.

Reversing 49 forms of être.

Nice! There’s some problem with the function signature, for which I’ve filed a ticket. I’ve also used the function in:

• reverse untyped list, Composition: accumulator (Z31639)
• append element, Composition: orchestration only (Z31632)

Another interesting (?) implementation is:

• lists have equal length, Composition: recursive (Z31503), with tail-recursion on both lists.

In T417018#11610162, @cmassaro wrote:

Hopefully! There are some aspects of tail recursion that will require additional work (namely, an extra abstraction to track whether an arbitrary set of resolution operations from one Z7 leads to another Z7), but for the uses of Z812 in particular, I suspect we'll be able to get some improvements. The type de-referencing will hopefully be fixed in V2, as well. I'm now going to make liberal use of your function as a test case, hehe.

apine opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/549

Draft: Support stack/rate limits in composition language v2; test that stack size doesn't grow in tail() compositions.

ecarg merged https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/549

Support stack/rate limits in composition language v2; test that stack size doesn't grow in tail() compositions.

Change #1240291 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-02-11-121010 to 2026-02-18-140059

https://gerrit.wikimedia.org/r/1240291

Change #1240291 merged by jenkins-bot:

[operations/deployment-charts@master] wikifunctions: Upgrade orchestrator from 2026-02-11-121010 to 2026-02-18-140059

https://gerrit.wikimedia.org/r/1240291