Am Mi., 16. März 2022 um 19:05 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> 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".

The reason why the typical library export should not be curried is two-fold:

(1) Future extensions that discriminate by the number of arguments
won't be possible anymore.

(2) Scheme is a dynamically typed language so for debugging it is
important that runtime errors are caught early (preferably at the
place where they logically originate). In particular, providing the
wrong number of arguments to a procedure should raise an assertion
violation at the time of application.

Extra exports are cheap, yes, but then you have fold and, say, fold-c
and you have to use the explicit "-c" versions for all your examples.
But then it is not even shorter (if that's a good measure stick) than
the other alternatives that don't need extra exports.

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

See above why this won't be such a good idea outside of demonstration
or pedagogical purposes.

> > In an earlier post, you gave the example
> > ...
>
> I don't have any issues with these alternatives; lambda* (curried)
> just does things differently.

And with the problems remarked above.

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

Maybe the point that is not clear to me is if SRFI 232 tries to solve
a practical problem, just wants to make the Hemann paper better known,
wants to make Scheme programming more like Haskell programming, or
just derives from some fascination with the form originally described
in that paper. Or, maybe, there's a fifth reason I haven't seen yet.

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

Thanks,

Marc

PS Although I don't endorse this SRFI in its current, please don't
misunderstand my critique in that I want to stop you from getting this
finalized. Once you are satisfied with this SRFI, by all means, get it
finalized.