My problem with it is that SRFI 1's fold (or fold-left to be more
precise) is not really a fold. Instead, it is the universal
catamorphism (the proper fold) composed with a reverse operation. The
latter, however, does not make sense for non-linear inductive data
types.

Am Di., 1. Sept. 2020 um 08:51 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> No, I meant distinction between srfi-1 fold and fold-left ('foldl' for Haskell).
> If the vector-flavor fold family took *-fold-left there wouldn't have been a confusion.
>
>
> On Mon, Aug 31, 2020 at 8:33 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> The distinction between fold-left and fold-right is a different thing
>>
>> fold/fold-left is iterative; fold-right is recursive.
>>
>> The discussion here, however, is about the order of the arguments of
>> the "kons" argument of "fold". SRFI 1's fold places in kons the single
>> seed after the variadic number of list elements. This is alien to the
>> usual calling convention of Scheme where a variadic number of
>> arguments comes last.
>>
>> PS Coming back to fold and fold-right. This is another thing that SRFI
>> 1 gets somewhat wrong. The fundamental operation is fold-right, which
>> is the catamorphism. So that operation should have gotten the simpler
>> name, not fold-left, which is the composition of the catamorphism with
>> list reversal. While this sounds just like abstract nonsense, it has
>> practical implications. For most data structures, the reversal does
>> not make sense. So given whatever inductive data structure, say a
>> tree, its fold, let's call it tree-fold necessarily has to be what is
>> called fold-right for lists in SRFI 1 and not fold.
>>
>> Am Di., 1. Sept. 2020 um 08:25 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >
>> > Srfi-1 fold is certainly an anomaly, but R6RS uses fold-left and fold-right and the distinction is clear.   As there are srfi-1 order folds as well, and srfi-1 has been around for a long time, I'd rather wish other 'standard foldl' protocol were named *-fold-left; then it'd be consistent with R6RS as well.  Alas.
>> >
>> >
>> > On Mon, Aug 31, 2020 at 7:59 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>> >>
>> >> Once we have an overview of all the fold-like procedures in the SRFIs,
>> >> we can think of adding a SRFI with somewhat streamlined versions. What
>> >> I am thinking is the following:
>> >>
>> >> All existing folds, which use the "wrong" order of SRFI 1, get a new
>> >> version named "foldx" (the "x" shall remind of "xcons") with the
>> >> "correct" (SRFI 133) order.
>> >>
>> >> Although this won't give us consistency in the names, this will give
>> >> us at least a consistent set of procedures. When should one use the
>> >> "foldx" instead of the "fold" version? Whenever efficiency matters and
>> >> tradition is not important.
>> >>
>> >> In the same SRFI, there should also be "starred" versions of all the
>> >> folds, e.g. fold*, which take only one sequence (e.g. a list) but any
>> >> number of seeds:
>> >>
>> >> (define (fold* proc lis . seed*)
>> >>   (let f ((lis lis) (seed* seed*))
>> >>     (if (null? lis) (apply values seed*)
>> >>        (call-with-values (lambda () (apply proc (car lis) seed*))
>> >>          (lambda seed* (f (cdr lis) seed*))))))
>> >>
>> >> NB With SRFI 210, it would look nicer:
>> >>
>> >> (define (fold* proc lis . seed*)
>> >>   (let f ((lis lis) (seed* seed*))
>> >>     (if (null? lis) (list-values seed*)
>> >>        (f (cdr lis) (list/mv (apply proc (car lis) seed*))))))
>> >>
>> >> (Even nice would be a named-let that can handle rest arguments as
>> >> multiple values without converting them into a list, but I am not sure
>> >> of how it would look like and whether it would fit into SRFI 210.)
>> >>
>> >> Marc