preliminary comments Peter McGoron (31 Aug 2026 13:12 UTC)
Re: preliminary comments Hernán Ibarra Mejia (01 Sep 2026 09:37 UTC)
Re: preliminary comments Peter McGoron (01 Sep 2026 11:10 UTC)

Re: preliminary comments Hernán Ibarra Mejia 01 Sep 2026 09:37 UTC

On Mon Aug 31, 2026 at 4:09 PM EEST, Peter McGoron wrote:
> 1. The MathML should be replaced with HTML <var>s, which are easier to
> render on older/simpler browsers.
>
> 2. > To constitute a monad, these procedures are required to satisfy
> some requirements, known as the monad laws, see any category theory
> textbook.
>
>     I think it would be very useful to spell out the monad laws in
> Scheme notation.
>

Agreed. Will make these changes.

> 3. Is `define/m` a definition form (i.e. can it be intermixed with some
> other definition forms, like define-syntax?) If not, then it should be
> renamed to something like `let/m`.

`define/m` and `return/m` are auxiliary syntax in the sense of R7RS (1.3.3):

> If category is “auxiliary syntax,” then the entry describes a syntax binding
> that occurs only as part of specific surrounding expressions. Any use as an
> independent syntactic construct or variable is an error.

I think I will add a note spelling this out. In particular, `define/m` binds a
variable in subsequent expressions, rather than in a new enclosing scope like a
`let` would do.

> 4. Is it possible to add a way to bind multiple values? For example,
> having `define-values/m` which is when bind passes N values to the
> procedure returned by the @ procedure, instead of 1.

That's an interesting thought. If I'm understanding correctly, we let @1 be an
expression returning N values of type Mt, and @2 be a function of N arguments of
type t, which returns a single value of type Mu. What I am not grokking is how
to use the bind procedure to combine @1 and @2 to produce a value of type Mu. If
you or someone else could clarify, and ideally provide a sample use, I would be
happy to add this.

> 5. > the variable _ should not appear in the body of the lambda.
>
>     This is a little confusing, as it seems to allow but discourage _
> appearing. I think "the variable _ is fresh" is simpler.

Agreed.

> 6. > The do/m syntax can be interpreted as follows
>
>     Is this can as in "are allowed to?" How normative is this definition?

These equalities should be enforced by the implementation. I will add a note.

> 7. > An SRFI-280-conformant implementation must report an error if a use
> of do/m does not syntactically conform to the grammar above
>
>     I think this should be relaxed. An implementation might want to add
> their own syntactic forms to the grammar. It would be possible with
> identifier properties to allow user extension, too.

Agreed. I was thinking of the error situations in the list below, but the
syntax could of course be extended.

> 8. In the sample implementation, `define/m` and `return/m` should be
> exported from the library.

As I remarked above, `define/m` and `return/m` are auxiliary syntax of `do/m`,
so I believe they should not be exported.

Thank you for the comments Peter.

Best wishes,
Hernán