Email list hosting service & mailing list manager

Argument order for folds Wolfgang Corcoran-Mathe (31 Aug 2020 19:26 UTC)
Re: Argument order for folds Marc Nieper-Wißkirchen (31 Aug 2020 19:34 UTC)
Re: Argument order for folds John Cowan (31 Aug 2020 20:01 UTC)
Re: Argument order for folds Marc Nieper-Wißkirchen (31 Aug 2020 20:07 UTC)
Re: Argument order for folds Arthur A. Gleckler (31 Aug 2020 21:06 UTC)
Re: Argument order for folds Marc Nieper-Wißkirchen (01 Sep 2020 05:59 UTC)
Re: Argument order for folds Shiro Kawai (01 Sep 2020 06:25 UTC)
Re: Argument order for folds Marc Nieper-Wißkirchen (01 Sep 2020 06:33 UTC)
Re: Argument order for folds Shiro Kawai (01 Sep 2020 06:51 UTC)
Re: Argument order for folds Marc Nieper-Wißkirchen (03 Sep 2020 08:56 UTC)
Re: Argument order for folds Shiro Kawai (03 Sep 2020 10:05 UTC)
Re: Argument order for folds Marc Nieper-Wißkirchen (03 Sep 2020 11:36 UTC)

Re: Argument order for folds Marc Nieper-Wißkirchen 01 Sep 2020 06:33 UTC

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