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 31 Aug 2020 19:33 UTC

Agreed. When ranges are like vectors, we should follow the SRFI 133 convention.

As we have seen, it is anyway the correct one and SRFI 1 got it wrong.

(The future will hopefully show us a way to mitigate this confusing
aspect of R7RS (large).)

Marc

Am Mo., 31. Aug. 2020 um 21:26 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> Since range-fold and range-fold-right are to take multiple ranges, we
> should switch the order of the arguments passed to the folded
> procedure.  As discussed in this[1] thread, I think we should prefer
> the SRFI 133/160 fold convention and pass the state value as the first
> argument and the (variable number of) range elements last, e.g.
>
>     (range-fold (lambda (acc . rest) ...) knil range1 range2 ...)
>
> and not
>
>     (range-fold (lambda (rest1 rest2 ... acc) ...) knil range1 range2 ...)
>
> [1] https://srfi-email.schemers.org/srfi-178/msg/15037069/
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "Computer science is no more about computers than astronomy is
> about telescopes." --pseudo-Dijkstra