I will respond to the Reddit post soon.

But please let us talk about possible static-type systems for Scheme
somewhere else as it feels off-topic for SRFI 241. At the moment it is
not even remotely clear what a "static Scheme" would look like so as
far as SRFI 241 is concerned, we should stick to RnRS Scheme.

Am Sa., 12. Nov. 2022 um 22:01 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
>
> An OCaml programmer has submitted some thoughtful feedback on SRFI 241 on Reddit.
>
> 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.)
>
> This is one of the main examples of why it's so important that we start to explore static types ASAP. Pattern matching is a workhorse of statically typed functional programming and would improve a lot of dynamically typed Scheme code as well. If RnRS standardizes a `match` syntax that doesn't fit well with the ML style, then dynamic and static Scheme will diverge on an important part of syntax and it will be hard to change course later.
>
> (Since Scheme has macros, everyone is free to write their own version of `match`, but good defaults matter.)
>
> On another note, we have another data point that ML coders have a thinking style which matches Scheme well (no pun intended). A joint language would be very productive.