On Tue Sep 1, 2026 at 1:03 AM EEST, Maciek Godek wrote:
> Like the opening rhetorical question, "Do monads need introduction
> anymore?".
> This probably depends on the addressee of the question, but there is
> nothing self-evident or obvious about the notion of monads. Conversely,
> they have a reputation of being hard to understand, and this should be
> telling.

"Do monads need introduction anymore?" is, to me, synonymous with "Monads were
not well-known but nowadays more people know about them." which is certainly
true. The next sentence spells this meaning out. I see no problem.

> Contrary to the statement in the abstract, monads are not "a fundamental
> concept in functional programming" (hint: functions are). Monads were used
> by Wadler in Haskell, to solve the problem of marrying I/O operations with
> lazy evaluation order. Haskell is a statically typed language with its
> original system of type classes. One could argue that Haskell's type system
> allows to track potential use of effects through functions' type signatures
> - but you don't have that in Scheme.

I will replace "fundamental concept" by "important concept" but this, in my
eyes, is a moot criticism. Monads are very important in our modern understanding
of functional programming.

> "Monads simplify common tasks in pure functional programming. Schemers tend
> not to be aware of monads because some monads are built into the language.
> If you have used continuations, lazy evaluation, or lists, you have been
> using monads."
>
> This isn't a very useful statement. In my experience Schemers tend to be
> well aware of monads.

Since it is subjective, I will remove the statement about Schemers not being
aware of monads.

> Moreover, the distinctive sign of monads in Haskell is (what is reflected in
> your proposal as well) the "do-notation" - and it's very misleading to claim
> that if someone used a list or function composition, or semicolons in C, then
> they "used" monads (because the concept of monad played absolutely no role to
> their users in most such cases).

Perhaps a better way to say what I meant is "(functional) programming constructs
can usually be expressed as an instance of a particular monad, and this
perspective often clarifies our understanding, if not the code itself". I will
consider changing the wording along these lines.

> Schemers have a culturally very different way of solving the problems that
> monads solve in Haskell. In particular, they have:
> - macros
> - interpreters (and the "quote" operator)
> - strict order of evaluation
> (and occasionally also first-class continuations)
>
> In my opinion, completely ignoring the Scheme's approach to solving various
> problems that Haskell solves with monads is a glaring omission, and any
> serious attempt to "bring monads into the language" should do an honest
> comparison between "monadic" and "monad-less" solutions to the same
> problems, so that the readers could judge for themselves which version they
> prefer.

Have you seen the Example section? It describes a standard problem, outlines a
natural but tedious functional solution, and gives a better monadic solution.

I am not saying that we should stop using idiomatic Scheme features in favour of
monads. What I am saying, and I think this is clear from the text, is that where
idiomatic Scheme is not enough, monads are a superb alternative. Usually side
effects fulfill this role, but there are any number of reasons to avoid them.
Ultimately, whether to use side effects or not is the programmer's choice;
monads help the programmer who decides to stay pure.

> Likewise, the proposal claims that "side effects can significantly slow a
> Scheme program, depending on the Scheme implementation", but does not show
> any actual benchmarks that would show that the variants that use the
> proposed framework are actually faster under any such implementation

Benchmarks are nice, of course, but in an SRFI they run the risk of becoming
grossly outdated. I think that "depending on the Scheme implementation" followed
by a passage from the documentation of a major Scheme implementation is evidence
enough.

I do wonder what other people think about the remarks on the performance of side
effect programming, and whether they are relevant or out of place. I am
undecided.

Thank you for your comments Maciek.

Best wishes,
Hernán