Amirouche, thank you very much for reading the spec.

I followed your suggestions; please find the hopefully improved draft
here: https://htmlpreview.github.io/?https://github.com/mnieper/srfi-241/blob/master/srfi-241.html

Thanks,

Marc

Am Mo., 12. Dez. 2022 um 12:17 Uhr schrieb Amirouche <xxxxxx@hyper.dev>:
>
> In SRFI-241, I can read:
>
> > Sometimes it is useful to explicitly name the operator in a catamorphism subpattern. Whereas ,[⟨variable⟩ …] recurs to the top of the current match, ,[⟨cata operator⟩ -> ⟨variable⟩ …] recurs to (the result of evaluating) ⟨cata operator⟩. ⟨Cata operator⟩ must evaluate to a procedure that accepts one argument, the matched value, and returns as many values as there are identifiers following the ->.
>
> Further down the document describe ⟨cata pattern⟩ as follow:
>
> > ,[⟨cata operator⟩ -> ⟨cata variable⟩ …]
> >
> > ,[⟨cata variable⟩ …]
>
> In the sample implementation, test-match.sps, here is an example use:
>
>   (define Expr
>     (lambda (env)
>       (lambda (x)
>         (match x
>           ...
>           [(let ([,v ,[e]]) ,[(Expr (cons v env)) -> body])
>             (guard (not (memq 'let env)) (symbol? v))
>             `(let ([,v ,e]) ,body)]
>         ...
>
>
> ref: https://github.com/mnieper/srfi-241/blob/edb8c72d179230435fe87fb15eae2a302f241e41/test-match.sps
>
> Compared to ,[⟨cata variable⟩ …] the explicit catamorphism ,[⟨cata operator⟩ -> ⟨cata variable⟩ …] is more general, because it allows to specify the procedure that will be used in the recurrence.
>
> Now that I have gone through it carefully, I understand the explicit catamorphism.
>
> Maybe my struggle is calling for an example following the paragraph "Sometimes it is useful to explicitly name the operator...".
>
> What do you think about introducing the general explicit catamorphism ,(proc -> production) before the shorthand syntax ,(x) ?
>
> Maybe it is typo: ⟨cata operators⟩ with an s to operator does not appear in match pattern language.
>
> The paragraph starting with "Semantics: A match expression ..." is dense. I wonder whether a bullet point approach will not make reading, and understanding the specification easier.
>
>