On Tue Sep 1, 2026 at 10:30 PM EEST, Marc Nieper-Wißkirchen wrote:
> SRFI 280 mentions SRFI 247 as a particular example of an ad-hoc monad
> implementation. This is not a good example for the purpose of SRFI 280.
>
> (...)
>
> Of course, SRFI 247 works well here because the monad here just threads a
> bunch of values through the computation.  For a more general monad like the
> list monad, other syntactic abstractions may be better.

You say so yourself: SRFI 247 works nicely in this example because it implements
a state monad. As I understand it (but please correct me if I'm wrong), SRFI 247
does not handle any other monads. Thus the phrase in the abstract "ad hoc
constructions only meant for specific monads" is, in my view, accurate (and the
title "Syntactic Monads" misleading).

> The reason d'être for the "syntactic" in the name is that they cause zero
> runtime overhead.  This won't be the case with SRFI 280 (unless one has a
> "sufficiently smart optimising compiler (TM)").

That's true, yet I never claimed that SRFI 280 is faster than SRFI 247, or even
easier to use. What I do sustain is that SRFI 280 works with any monad, whereas
SRFI 247 does not. I even go out of my way in the Rationale to say that SRFI 280
does *not* supersede SRFI 247, since SRFI 280 does not provide any facilities
for working with state monads specifically and SRFI 247 does.

> A few more general remarks: No one doubts that monads are an important
> concept and that they are ubiquitous.  But so are groups (in the
> mathematical sense), just because they are such a general notion.
>
> But one should not confuse the Haskell `do` notation with monads; the `do`
> notation makes working with monads simpler in Haskell.  It does not mean
> that "an implementation of monads" in another programming language needs to
> deliver a `do` notation, nor that it should.
>
> For example, the sentence "Programming with monads takes practice and some
> study." is misleading.  As likely every non-trivial program contains a
> construct that has a monadic interpretation, programming with a particular
> monadic API or recognising monads may take practice and some study.

I agree that that particular sentence is superfluous and I will remove it. But I
can't discern what else, if anything, you are criticising. If it is the phrase
"monads are important in functional programming", I think that's fine to leave
in the text for people not aware of them.

> P.S.: I agree with some of Maciek Godek's points.

It would be more helpful to specify which points and why. I already addressed
all of them in that thread.

Thank you for your comments Marc.

Best wishes,
Hernán