Subject: bug#78656: [PATCH] Add new reduction primitives `fold-left' and `fold-right'

From: Zach Shaftel <[email-masked]>
Date: Sun, 01 Jun 2025 13:38:41 -0400

Eli Zaretskii <[email-masked]> writes:

> We already have seq-reduce, so fold-left seems to be unneeded? 

i don't disagree. the intent was to simply have `seq-reduce' provide a
generic wrapper over `fold-left', the way `seq-do' and `seq-map' do for
`mapc' and `mapcar'. but i really only added `fold-left' because i was
already adding `fold-right', and it kinda felt weird to have one without
the other.

> As to fold-right, couldn't we just add another function to seq.el? Or
> are there good reasons to have these implemented in C?

the main reason was for `fold-right' to use a C array to temporarily
hold list elements, instead of needing to `vconcat' or `reverse' the
list first. that's not hugely problematic, and i think an elisp
implementation would also be fine.

more generally, my thinking is that reduction is a core operator in
functional programming, which has become a dominant style in the elisp
ecosystem, so it would be nice to have a speed/space efficient
implementation. i assumed that's why `mapcar' is in C.

but, ultimately i knew this might not be a good fit. i was just curious,
and also wanted to see how well i understood the C internals.