The basis of including something in a SRFI is convenience rather than minimality.  If it is heavily used, then it may as well be present here without depending on a monad SRFI.  I do have a pre-SRFI for monads and their relatives at <>.

On Tue, Mar 31, 2020 at 1:01 PM Wolfgang Corcoran-Mathe <> wrote:
On 2020-03-30 15:06 -0400, John Cowan wrote:
>Makes sense. I have generalized these to accept any traversable container
>by passing a for-each procedure to take apart the container and a
>constructor to reassemble it.  I have also added an Either equivalent.
>On Mon, Mar 30, 2020 at 12:07 PM Arvydas Silanskas <
>> wrote:
>> I think it's missing sequencing, for which I personally reach quite often
>> when working with such monadic container types. Eg. for Maybe:
>> (sequence-maybe lst)
>> if all elements in lst are Just, returns Just of list, whose elements
>> correspond to unwrapped values in lst. If any element in lst is Nothing,
>> returns Nothing.
>> (sequence-maybe (list (just 'a) (just 'b))) == (just (list 'a 'b))
>> (sequence-maybe (list (just 'a) (nothing))) == (nothing)

I think this is a very useful addition.  One thought is that, since
a `sequence' operation can be generalized to any type with a `bind'
operation, it could be defined in a future "monads" SRFI rather than
being implemented (twice!) here.


Wolfgang Corcoran-Mathe  <>

"Scientists must be optimists at heart, in order to block out the
incessant chorus of those who say 'It cannot be done.'"
--Academician Prokhor Zakharov