On 6/9/20 11:58 AM, Marc Nieper-Wißkirchen wrote:

> Am Di., 9. Juni 2020 um 17:47 Uhr schrieb Arne Babenhauserheide
> <xxxxxx@web.de>:
>
>> maybe chaining?
> Chaining is nice because it reminds one of the chaining rule in
> calculus, which is about the composition of functions.
>
> However, `->' does not only compose functions, it also applies the
> composition to some initial argument. So it is really the monadic
> bind, not just a compose/chain operation.
>
> (bind x f g h)
>
> doesn't look too bad, does it?
>
> In the general monadic framework that is taking shape, it would be
> defined (yet to be extended to multiple values) just by
>
> (define (bind x . f*)
>    (fold (lambda (f x) (f x)) x f*))
>
> The syntactic sugar can be provided by SRFI 26 as in:
>
> (bind x (cut f 1 <>) (cut g <> 2))
>
> This makes it pretty obvious and explicit (and, I would say, in the
> tradition of Scheme) how the parameter is threaded through.

I'm wary of explicitly connecting this SRFI to monads in any way. Monads
are a difficult concept for new functional programmers, are not a core
part of Scheme, and can be difficult to use in a dynamically-typed language.

Requiring `cut` also seems like too much. Like the `let*` proposal, it
makes short pipelines longer and more confusing than they would have
been as simple nested expressions.

What needs to be kept in mind here is that the sole purpose of threading
macros is brevity and readability. If this SRFI is defined in a way that
sacrifices either of those, there will be no reason to use it, because
writing expressions plainly, without the threading operator, will always
be clearer.

With that said, I am open to a different name for the default operator.
Right now I'm torn between `seq`, `pipe`, `chain`, and `=>`. I'm also
seriously considering removing the `->`/`->>` distinction and making
`->>` the default when no `<>` is present, since the most prominent use
case for this operator (chained list/vector transformations) passes the
chained argument in the last position.