Hi Adam,

thank you very much for your quick responses and the second draft!

If you allow, I would like to make a number of comments again (but
don't worry, these are fewer than before :)):

(1) While the new title is IMHO much better than the previous one, it
is still slightly misleading. In the current version of the SRFI, the
"<>" syntax is only usable at the top-level. So it is more about
"procedure (call) chaining operators" than general expression chaining
operators. That said, it is always good if hard-to-understand
restrictions are being lifted. So, it would make the most sense if the
arguments that follow "chain" are arbitrary expressions when used
together with "<>". (This may only be implementable if multiple values
are restricted to the "<...>" syntax and not to multiple occurrences
of "<>" but this is not such a big restriction as is the restriction
to the top-level.)

(2) The library should export "<>" and "<...>" bound to the same
values an implementation of SRFI 26 would bind them to. (See my
comment in the section "Auxiliary syntax" here:
https://srfi.schemers.org/srfi-148/srfi-148.html.)

(3) The restriction that pipeline steps without an explicit "<>"
expect exactly one value looks artificial from a language designer's
point of view (and from the point of view of a mathematician). I would
drop it.

(4) The new name "chain", I like much better than the symbol "->"
because it immediately makes the code look more Scheme-like! However,
the naming is slightly misleading. What you call "chain-lambda" is, in
fact, a simple "chain" (in the sense of composition) of a chain of
procedures. What you call "chain" on the other hand, is a composition
of functions together with the application of this composition to an
initial value. As I said before, the latter operation has already been
named "bind" in several places. If you want to stick to the
"chain"-prefix, I would replace "chain" by "chain-bind" and
"chain-lambda" by "chain".

(5) Does the "chain-lambda" (or "chain" under my proposal (4)) allow a
rest argument when both "<>" and "<...>" are given? That would be a
good thing.

(6) The syntax-rules implementation has grown significantly (thanks
for all the heavy work!!!) and becomes hard to read (as inevitably
so). Would you mind to add a `syntax-case' implementation as well for
those Schemes that support it? It will be easier to understand if one
just wants to understand the specification.

(7) Change your baking recipe to use the metric system. We don't live
in the 19th century anymore. :)

Am Do., 11. Juni 2020 um 07:43 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> I've just published draft #2 of SRFI 197. It was submitted by Adam Nelson, author of the SRFI.
>
> Note that the title has changed from Threading Macros to Expression Chaining Operators.
>
> Here are Adam's comments on the draft:
>
> Notable changes:
>
> The SRFI name has been changed to "Expression Chaining Operators".
> The names of the operators have been changed. Instead of ASCII arrows, they now use the word "chain".
> The operators have been reduced to just four: chain, chain-and, chain-when, and chain-lambda. All of these place the threaded argument last, like ->>.
> Atoms are not allowed as pipeline steps. All steps must be lists now.
> I've adopted SRFI 26 syntax to move the threaded argument by marking its location with <>. Multiple return values are also supported with this syntax.
> The rationale section now addresses the equivalence between let* and chain.
>
> Here is the commit summary:
>
> second draft from Adam Nelson
> Remove trailing whitespace.
> Restore date of first draft.
> Update title.
> Fix punctuation.
> Generate.
> Add missing parenthesis.
> Publish second draft.
>
> Here's the diff:
>
> https://github.com/scheme-requests-for-implementation/srfi-197/compare/draft-1..draft-2
>
> Regards,
>
>
> SRFI Editor