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
John Cowan
(13 Jun 2021 00: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