On 6/9/20 12:45 PM, Marc Nieper-Wißkirchen wrote:

> 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.
I think I misunderstood your intention when you mentioned "the general
monadic framework that is taking shape", then. I assumed that you were
talking about bringing in SRFI 165 monads and replacing `->` with a
`bind` operation that works on both those and ordinary procedures, which
seems like scope creep.
> (What do you mean by "difficult to use in a dynamically-typed
> language"? That is an orthogonal concept, isn't it?)
Yes, this was more of a concern about SRFI 165 and similar attempts to
bring monads into dynamically-typed languages, which usually result in
code that is difficult to follow because of the lack of type
annotations. It probably wasn't relevant to bring into this conversation.
> 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.
True, but it changes the tipping point at which `->` expressions become
easier to read than equivalent plain expressions. Using the `cut`
approach on chains of 3 or fewer calls doesn't accomplish much beyond
adding noise.
> (let* ((<- xs)
>          (<- (map (lambda (x) (+ x 1)) <-)
>          (<- (filter odd? <-)
>          (<- (fold * 1 <-))
>    <-)
This is an interesting expression, and it does kind of communicate that
chaining is taking place. It also establishes a good baseline: threading
macros should be at least terser than this kind of `let*` expression, or
else they serve no purpose. I agree that unifying `let*` and `and-let*`
syntax would be helpful, but that should be a different SRFI, and
probably should not include the `cut` syntax.
> And the fact, that `->' maps in syntax and semantics so easily to
> `let*' lets us explain `->' in Scheme terms.
I should consider using this as a way of explaining these macros in my
next draft.