Email list hosting service & mailing list manager

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