New draft (#10) of SRFI 224: Integer Mappings
Arthur A. Gleckler
(17 Jun 2021 04:10 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings
Marc Nieper-Wißkirchen
(17 Jun 2021 05:32 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings
Wolfgang Corcoran-Mathe
(17 Jun 2021 05:50 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings
Marc Nieper-Wißkirchen
(17 Jun 2021 13:57 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe (17 Jun 2021 17:32 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings
Marc Nieper-Wißkirchen
(18 Jun 2021 05:49 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings
Wolfgang Corcoran-Mathe
(18 Jun 2021 06:30 UTC)
|
Re: New draft (#10) of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe 17 Jun 2021 17:31 UTC
On 2021-06-17 15:56 +0200, Marc Nieper-Wißkirchen wrote: > * Naming convention issue: SRFI 146 uses the suffix "/reverse" while SRFI > 224 seems to use the infix "-decreasing-". SRFI 224 has "decreasing-" in the case of fxmapping->decreasing-alist and fxmapping->decreasing-generator, but the increasing counterparts are not named as such. We also have "fold" and "fold-right" (names borrowed from Haskell's IntMap library) instead of 146's "fold" and "fold/reverse". I find the "fold/reverse" name a little questionable, since fxmappings are sets and not inherently ordered. But I'm not completely satisfied with the current collection of names. > * fxmapping-accumulate should probably guarantee to tail-call "proc". > > * The same is true for fxmapping-update and similar procedures. Are the current semantics not enough? As these procedures are specified, they clearly deliver their results to the original continuation. What advantage is there in requiring them to tail-call their procedure arguments? -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> "Searching for fulfillment in this compact subset of existence... My life must have a convergent subsequence somewhere... out there..." --Abstruse Goose