Email list hosting service & mailing list manager

New draft (#9) and last call of SRFI 224: Integer Mappings Arthur A. Gleckler (11 Jun 2021 01:16 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe (11 Jun 2021 02:00 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Marc Nieper-Wißkirchen (11 Jun 2021 05:35 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe (11 Jun 2021 14:41 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Marc Nieper-Wißkirchen (11 Jun 2021 15:18 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Marc Nieper-Wißkirchen (13 Jun 2021 08:39 UTC)

Re: New draft (#9) and last call of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe 11 Jun 2021 02:00 UTC

On 2021-06-10 18:16 -0700, Arthur A. Gleckler wrote:
> I've just published draft #9 of SRFI 224

Arthur, thanks for publishing this.

Although I didn't remove the question from the "Issues" section,
I've decided to keep the Maybe/Either-dependent procedures in the
SRFI.  (That is, there will be no optional "Maybe sublibrary".)

For the record, my reasoning is as follows: Implementors who like
Maybe and Either will implement the whole SRFI and those who dislike
them (but like the rest) will provide a subset without those forms.
I hope most will take the former approach, but I doubt that downgrading
these forms to "optional" status will convince anyone *deeply*
opposed who would be inclined to ignore the SRFI due to their
presence.  I also don't see a reason to introduce the complexity
of a sublibrary (which every user would have to check for and perhaps
import separately) when, again, implementors are free to create
their own sublibraries if they see fit.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"This isn't right. This isn't even wrong." --Wolfgang Pauli