Am Fr., 12. Juni 2020 um 03:14 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>
> On 6/11/20 5:57 AM, Marc Nieper-Wißkirchen wrote:
>
> (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.
>
> If you have a better name, I'm open to it. I feel like "call chaining" might be unclear, and "procedure call chaining" is misleading because it implies a limitation that isn't there (the chained calls can be procedure or macro calls).

As no scoping for "<>" is implemented and the implementation more or
less does a textual substitution, macro calls are even less supported
than I thought in my previous reply. Any macro where some of its
arguments end up being quoted and where we give "<>" for such an
argument, it will be replaced by some symbol representing a temporary
generated by the syntax-rules machinery.

So it's really only chaining of procedure calls, which, I think, is
fine for the scope of the SRFI. (And, in fact, it would probably be
too hard to formally specify more.)

(8) The current syntax (with the implicit "<>" at the end) does not
cater for the case when a step returns zero values (except for some
hack with "<...>" at the end). The whole thing would be more regular
if no "<>" meant zero values.  Of course, a chain where one step
yields zero values can be broken into two chains, but this is hard to
do when the chain expression is generated by some other macro. (This
is one reason why regularity matters. Scheme expressions are not only
typed by the user but are often generated by macros.) This would also
be in line with SRFI 26, where no "<>" means a procedure of zero
arguments.

(9) SRFI 26 allows one to substitute the operator of a procedure call.
I haven't check the implementation of SRFI 197, but I haven't seen a
test for (chain + (<> 1 2)), which should evaluate to 3.

(10) I am not sure, but maybe the following procedures (which could be
provided natively by the implementation to make them fast) could help
in implementing multiple values more efficiently:

(bind x f1 ... fn f) => (call-with-values (lambda () (bind x f1 ... fn)) f)
(bind x) => x

(compose f1 ... fn) => (lambda arg* (bind* arg f1 f2 ... fn))

where bind* is defined by

(bind* x f1 ... fn f) => (call-with-values (lambda () (bind* x f1 ... fn)) f)
(bind* x f) => (apply f x)
(bind* x) => (values x)