Am Di., 9. Juni 2020 um 18:21 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:

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

The trivial monad (underlying SRFI 197) is a trivial concept. ;)

Joking aside, I am not so sure whether the phrase "are not a core part
of Scheme" makes as much sense as it seems to make. As being said,
monads are a concept as is the concept of a group or a ring. Certain
patterns just fulfill the axioms of a monad or a ring.

Apart from a side remark (which will help those who know monads), I
would neither make the connection explicit. But it makes sense to have
a syntax that can be easily copied over to the many non-trivial monads
we have already defined or will be defining.

(What do you mean by "difficult to use in a dynamically-typed
language"? That is an orthogonal concept, isn't it?)

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

Longer yes; the `let*' may or may not be more confusing (depending on
whether you know `and-let*' or not); but the explicit use of `cut'
would definitely make it more, err, explicit and, thus, easier to
understand.

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

That's certainly a good point although there is some area of tension
between brevity and readability and generally depends on a number of
parameters and one's palate.

(let* ((<- xs)
        (<- (map (lambda (x) (+ x 1)) <-)
        (<- (filter odd? <-)
        (<- (fold * 1 <-))
  <-)

is no less pretty! (Although a `let*' syntax that allows an empty body
and whose value is then the value of the last bound variable would be
even better. Maybe, we should propose this extension for R7RS-large
because `and-let*' already allows this. Someone should make a SRFI for
this!!!)

And the fact, that `->' maps in syntax and semantics so easily to
`let*' lets us explain `->' in Scheme terms.

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

That sounds helpful.