Am Fr., 11. Juni 2021 um 04:00 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>:

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

Thanks for your patience with all these last-minute issues, Wolfgang and Arthur.

Will SRFI 217 also receive an update (fxsets instead of isets)?

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.

Providing just a subset wouldn't be a good decision for an implementer. If this became a model, code intended to be practically portable wouldn't be able to use the Maybe part. Should this be foreseeable, a cheap extra library would be better.

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.

While I like that Scheme has now a "semi-official" way to express Maybes through SRFI 189, I have to admit that I oppose a lot of their uses in SRFI 224. In fact, IMO, fxmapping-lookup is a good example where Maybes are worse than the traditional fxmapping-ref. Not only is the former less Scheme-y (but this is somewhat subjective), it is also an example of needless allocation of objects on the heap. IMO, idiomatic code should only create Maybes when they have to be stored. In the given example implementation of fxmapping-ref, however, they are created just to be destructed again. IMO, that's a bad use and not a very good example. fxmapping-ref should be the primitive procedure, and one could give an implementation of fxmapping-lookup in terms of fxmapping-ref.