Below is the complete feedback (commented by me) that was posted on Reddit.

> OCaml programmer here. I use match all the time when I write Scheme (I use the (ice-9 match) module of Guile), and I'm happy to see this being considered. I am not familiar with the implicit-recursion aspect of the present proposal, so comments on it.

Thank you for your valuable feedback.  As you probably have figured
out Guile's match is not the special form that is described in this
SRFI.

(If you use (Guile's) match all the time when you write Scheme, I
wonder whether you write idiomatic Scheme code; see below.  Maybe you
can post an example of what you would like to solve using SRFI 241.)

> Personally I find "catamorphism" a rather unclear name. It is very jargon-y. It is of course way better than other names like "histomorphism" or "zigomorphism", but still I would be very hesitant to use this name in front of someone who may not know precisely the reference. I would rather use a more discoverable name like "implicit recursion" or what not.

I will think about it; catamorphism is less generic than "implicit
recursion", so it should be clearer.  I think it is good (if not
important) for "functional" programmers to know (roughly) what a
catamorphism is.

> I commonly write functions that take several parameters, including one on which the recursion is being performed, but the recursive calls on sub-parts of the input also change the other parameters. For example (in OCaml syntax):
>
> .
>
> type 'a tree = Leaf of 'a | Tree of 'a tree * 'a tree
> type path = Root | Left of path | Right of path
>
> let rec explore_tree path tree =
>   match tree with
>   | Leaf ... -> ...
>   | Node (left, right) ->
>     let vleft = explore_tree (Left path) left in
>     let vright = explore_tree (Right path) right in
>     ...
>
> How would you express this in this syntax? (Or is it intentional that "catamorphisms" do not suppor this?) I believe that this is what the ,[<cata operator> -> <cata variable>...] part is supposed to be doing, and I think I can see how it would work, but I think that an example of this should be included in the proposal document.

If you want to use SRFI 241 for it, it would look like this:

(define explore-tree
   (lambda (path tree)
     (define explore-left (lambda (tree) (explore-tree `(left ,path) tree))
     (define explore-right (lambda (tree) (explore-tree `(right ,path) tree))
     (match tree
       [(leaf ,x) ---]
       [(node ,[explore-left -> vleft] ,[explore-right -> vright]) ----])))

That said, in my opinion this is not good Scheme code since record
types have been standardized.  Especially in a language with dynamic
typing, it is important to have strong runtime types; using general
lists to model trees, however, is an example of very weak typing.
Moreover, it is not very efficient.  Three allocations are needed for
`(node ,left ,right) where the original ML example only needed one
(record) allocation.

So the following would be much better:

(define-record-type tree)
(define-record-type node (parent tree) (fields left right))
(define-record-type path)
(define-record-type root (parent path))
(define-record-type left (parent path) (fields path))
(define-record-type right (parent path) (fields path))

(define-syntax tree-case (lambda (stx) ---))

(define-explore-tree
  (lambda (path tree)
    ...
    (tree-case tree
      [(leaf ,x) ---]
      [(node ---) ---])))

The only problem is that you have to write the tree-case macro
yourself (or replace `tree-case' by a general cond expression).

Please see the Nanopass framework (documented in Racket, for example,
but existing independently) that makes this automatic.  At some point
in the future, I plan to submit a SRFI that offers similar
functionality.

Now, what is SRFI 241's match for, one may ask.  Well, exactly for
when one has to "fold" over Scheme data, i.e. the kind of data that
the `read' procedure yields.  Writing a compiler is one application.

(This does not mean that one couldn't use it for prototyping what
would later be type-safe code employing records.)

>
> 3. Why are the <cata variable> restricted to be variables and not, again, patterns?

The <cata variables> hold the result values of the catamorphism
defined by the match form.  In general, it does not make sense to
match them again.

> Finally, a minor note: in my experience with OCaml or other ML languages, it matters that all language forms that accept term-level binders (| x -> ... but also fun x -> ..., let x = ... etc.) also accept patterns, not just a single match construct. In Scheme I use let-match, lambda-match on a regular basis. Unfortunately these are less pleasant to use in my experience than the ML equivalent, because they are non-standard forms with heavier syntax than the standard forms (I can't just start replacing variables somewhere with a pattern). I think that an ideal Scheme these days should integrate pattern-matching more deeply in the language to be really convenient. (This is not to criticize efforts to standardize at least one match construct, it would be very nice.)

See my general comment above.  If you use let-match and lambda-match
regularly you are, at least in my opinion, probably not writing the
best Scheme code; Scheme has multiple values so where ML would need
records, for Scheme you would use apply and receive (SRFI 8).  And if
you need structured data, you should use records.  Scheme should have
an easy way to define data types using records and to
construct/destruct them, but something like the Nanopass framework is
not yet standardized.

Am Sa., 12. Nov. 2022 um 00:40 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> An OCaml programmer has submitted some thoughtful feedback on SRFI 241 on Reddit.  I've encouraged them to join the mailing list, but it would be great if you would take a look, Marc.
>
> Thanks.