Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:
>> I have no intention of using the term "bind" in this SRFI, because its meaning is unclear to users who are not experienced functional programmers. And, while I see your point that "chain" makes just as much sense as the name of the lambda builder macro, the macro currently called "chain" is likely to be used more often than the one named "chain-lambda", so it makes sense that it would have the shorter name. Pipelines are often written without a newline before the first entry, and increasing the length of "chain"'s name will increase the indentation and make it harder to write pipelines this way.
>
> "bind" is even one letter shorter than "chain". :) I don't get the
> point about the meaning being unclear. While "bind" may only be known
> to some, the name "chain" is so universal that one cannot infer the
> operation from this name either, whether being a functional programmer
> or not.

Chain has a matching meaning in common language: Doing things one after
the other. As in "the chain of command". But it does not imply replacing
arguments in the links.

Bind has no similar common meaning. Bind glues things together. But it
does not imply doing things one after the other.

If I can disentangle it correctly, bind is what is done with the first
element. Chain is what is done with the rest.

We chain the rest to the first element.
We bind the first element into the rest.

One nice usecase (that might be a good candidate for the docs):

(for-each (chain-lambda
            (+ 1)
            (expt <> 2)
            (format #t "~a\n"))
  (iota 4))

> No problem! I usually have very decided opinions, so I have to live
> with that not everyone shares them. But I try my best to preserve the
> beauty and the unique characteristics of Scheme.

I believe that’s what most of us are trying to do by contributing here.
Even though I don’t agree with all you write: Thank you!

And another thing I want to thank for: In this discussion I learned
about and-let* and I realized that I’ve made my life much too hard in
map expressions, because many of my usecases for lambda in map have much
cleaner expressions with cut.

(and-let* ((foo (assoc 'foo '((foo . bar)))))
  (display foo)
  (newline))

(map (cut expt 2 <>) (iota 10))

One thing I’m still missing is and-let*-values:

(and-let*-values (((foo bar) (values 'foo 'bar)))
  (display foo)
  (display bar)
  (newline))
;; versus
(and-let*-values (((foo bar) #f))
  (display foo) ;; never executed
  (display bar)
  (newline))
(and-let*-values (((foo bar) (values #f 'bar)))
  (display foo) ;; executed?
  (display bar)
  (newline))

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken