It is still not clear to me how to use SRFI 232 in practice. In order not to increase the danger of hard-to-catch errors, we won't want the typical library export (of whatever library) to be curried. But exporting all procedures in an ordinary and in a curried version is also not a viable option.

In an earlier post, you gave the example

(compose (map make-pair-sum)
       (filter prime-sum?)
   (append-map pair-over-interval))

which really would be something like

(compose (map-c make-pair-sum)
   (filter-c prime-sum?)
   (append-map-c pair-over-interval))

Now why is this any more readable than, say

(compose (γ map make-pair-sum)
(γ filter prime-sum?)
(γ append-map pair-over-interval))

[replace γ = c = "curry" by your favorite symbol] or

(compose (map make-pair-sum _)
         (filter prime-sum? _)
         (append-map pair-over-interval _))

?

The latter two versions don't need an extra curried export for each procedure.

Marc

PS I see the theoretical fascination with the Hemann paper, but I also would like to see a practicable addition to the Scheme language (and that doesn't mistake it as a Haskell with parentheses but that's a different point).

PPS After giving it a bit more thought, I have come to the conclusion that you should re-add the thunk case for consistency even if it is not as useful as the rest; the cut macro of SRFI 26 also allows cut expressions without any slots or as many slots as the procedure has arguments, etc.

(curried () ...) would be a synonym for (let* () ...) or (let () ...) and, as such, is already useful (when you wrap things in a body). (As one can see, let* with zero bindings is as useful as curried with zero formals. And the case of zero bindings has neither been superficially excluded from the let* spec in the report.)

Am Di., 15. März 2022 um 00:57 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>:
>
> On 2022-03-14 19:33 +0000, siiky wrote:
> > On 3/14/22 18:51, Marc Nieper-Wißkirchen wrote:
> > > curried is better the curry because the defined procedure is not the
> > > curry procedure but a curried procedure.
> >
> > I see what you mean. `curry` would be more apropriate for a function that
> > curries an existing procedure.
>
> I do like 'curried'. I suppose I only considered 'curry', for some
> reason, but the adjective probably makes more sense than the verb
> here (for the reason Marc cited).
>
> --
> Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>