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)
|
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