> From: Adam Nelson <xxxxxx@nels.onl>
> Date: Tuesday, June 09, 2020 11:17 AM
>
> 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.

Indeed.

> [ Monads and cut. ]
>
> 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.

Absolutely.  Compare to the regular expressions SRFI 115, which has some
good arguments for its longwinded SREs to avoid the strings ever other
programming or system that I'm aware of uses, and is easy enough to
translate to and from.

> With that said, I am open to a different name for the default operator.
> Right now I'm torn between `seq`, `pipe`, `chain`, and `=>`....

Chaining works at least as well for me as pipelining, perhaps better
since we of course already have pipelining in shells at a much closer
level to our code than CPU pipelining.  Those of us who've used UNIX
for a long time already have a strong association with it.

Which I doubt is true for anything related to "chains" for most or all
of us, at least in orthogonal ways vs. the chain rule.  While still
preferring a non-alphabetic based syntax as inspired by Clojure for
how it stands out in code, "chain" looks likely to work fairly well,
is for me more striking, unusual, than "pipe" or "seq".

- Harold