Re: Upcoming changes to the SRFI
Peter McGoron 06 Sep 2026 02:28 UTC
> - default-monad is a R7RS parameter. When the [monad] argument is missing in
> return, bind, join, and lift, (default-monad) is assumed.
I would be a little concerned by this. Setting the monad in one part of
the program could cause difficult to debug issues in another part of the
program if you're not careful. Also, the common definition of
`parameterize` does not tail-call its body, which means some iterative
algorithms may blow the stack.
I don't know enough about the design of everything else to suggest an
alternative. However, when I do something that is like "monads" (writing
parser combinators[1] or similar[2]) I usually have as much as possible
be higher order procedures that return higher-order procedures, and use
an entry point to run the whole thing with given arguments. This is
similar to the current draft, but the current draft doesn't have a
procedure to run everything, which is implicit in the do/m macro (or
equivalent). This might be a good way to compose fragments together
without needing to rely on parameter objects.
So if the library were designed around how I did [1] and [2],
(monadic-let ((x foo) (y bar))
(baz x y)
(return buz))
Would create some object that can be passed as "obj" to (monadic-run
monad obj), obviating the need for the parameter object.
[1]: https://florida.moe/phosphate/
[2]: https://florida.moe/nitrate/
> [syntax] (monadic-let <bindings> <body>)
> [syntax] (monadic-let* <bindings> <body>)
What is the difference between `let` and `let*`? In my mind, monads are
sequential, so `let` and `let*` seem to be the same (minus scoping rules).
> I also plan to add a lot more examples, and incorporate the changes
I agreed to previously. Even though it's not what I originally
envisioned, I will assume the reader knows nothing about monads, and
change my writing accordingly.
As someone with no formal math or CS background and who has never used
Haskell, this would be a great help.
-- Peter McGoron
