Am Mi., 2. Sept. 2026 um 15:15 Uhr schrieb Hernán Ibarra Mejia
<xxxxxx@ibarramejia.com>:
>
> 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).

My criticism is not that SRFI 280 fails to provide a generic monadic
interface.  It clearly does.  My concern is rather that parts of the
rationale seem to argue from the general importance of monads to the
usefulness of this particular interface and syntax, without
sufficiently separating those two questions.

> > 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.

You mention efficiency later, when comparing pure and impure code. I
don't think that argument supports SRFI 280 very well, though: if
expressing a computation through the SRFI 280 interface introduces
overhead compared with the corresponding idiomatic pure or impure
Scheme code, then the potential optimisation advantages of purity are
a separate issue.

That said, pure code has other advantages over impure code.

(One should note, though, that it is very hard to define in a
mathematical precise way what "purity" actually means in sufficiently
absolute terms.  A good approximation that works for Scheme seems to
be that code is pure if it is transparent with respect to call/cc.)

Coming back to efficiency: please take a look at SRFI 265. It gives
you a framework on top of which one can implement monadic notation by
macro expansion, much like Haskell's do notation is translated into
applications of the monadic operations. This can make the abstraction
compile away and permit code as efficient as the corresponding
idiomatic Scheme code.

> > 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.

The phrase "monads are important in functional programming" is of
little help to readers who are not already familiar with them,
especially as SRFI 280 does not seem to be aimed at teaching what a
monad is or how monads are used idiomatically (at least in the Haskell
world).

I think my principal point of criticism is basically this: someone who
already knows monads, the general idioms of functional programming,
Scheme, and Haskell does not need much of the explanatory text, and
some of the rather promotional wording may actually make technically
knowledgeable readers more sceptical rather than less so. For a reader
unfamiliar with the subject, on the other hand, the explanations are
too brief to be self-contained.

More importantly, for that audience the SRFI does not distinguish
clearly enough between the mathematical concept of a monad and one
particular Scheme API and syntactic interface for programming with
monads, strongly reminiscent of the Haskell presentation. The general
importance or ubiquity of monads is not, by itself, an argument for
this particular interface, just as the ubiquity of groups in
mathematics would not by itself motivate introducing one particular
generic "group interface" into a programming language.

> > 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.

I will chime in on the discussion between you and Maciek if I think
some points remain insufficiently addressed.

> Thank you for your comments Marc.

And thank you for your prompt replies.

Marc

>
> Best wishes,
> Hernán