On 2022-03-15 13:53 +0100, Marc Nieper-Wißkirchen wrote:
> 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.

On the contrary, I don't see why "the typical library export"
shouldn't be curried, provided the author makes it clear that this is
what you should expect.  And, if both are useful in some specific
cases, why *not* export both curried and un- forms?  Exports are
cheap.  I also don't understand why the alternatives you suggest are
"everything is curried" or "nothing is curried".

It's also not far-fetched in the Lisp world for someone to write a
quick meta-language in which all core procedures *are* curried.

> In an earlier post, you gave the example
> ...

I don't have any issues with these alternatives; lambda* (curried)
just does things differently.

> 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).

You know this, but we are a long way from talking about standardizing
curried.  Schemers can happily ignore this Request for Implementation
if they don't like what it does.  This is but one stall in the bazaar.

I hope the SRFI doesn't give the impression that it's somehow
"Haskell with parentheses".  I'll review the rationale, etc..

> 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.

Thanks, I'll consider this.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>