GNU bug report logs - #78656
[PATCH] Add new reduction primitives `fold-left' and `fold-right'

Previous Next

Full log

Message #14 received at 78656 <at> debbugs.gnu.org (full text, mbox):

From: Zach Shaftel <zach <at> shaf.tel>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78656 <at> debbugs.gnu.org
Subject: Re: bug#78656: [PATCH] Add new reduction primitives `fold-left' and
 `fold-right'
Date: Sun, 01 Jun 2025 13:38:41 -0400

Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.