I've made some updates to the sample implementation at
https://github.com/ar-nelson/srfi-197, including a syntax-case
implementation. It's about the same length as the syntax-rules
implementation, but it might be easier to read. I also added
SRFI-148-style placeholder macros for <> and <...>.

Also, in the process of trying to implement these placeholders, I
discovered a reason that the syntax parameters approach to <> and <...>
probably can't work: as far as I know, unless there's a SRFI I don't
know about (which could be the case), there's no standard way to
implement identifier macros in Scheme. A syntax parameter could define
(<> ...), but not <> by itself. (R6RS syntax-case can do this, but R7RS
can't.)

I'm starting to write a third, hopefully final draft. I don't plan to
add any new features, but I hope to include more detailed
specifications, including the suggested formal syntax section.

On 6/15/20 6:56 AM, Marc Nieper-Wißkirchen wrote:
> 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.
This is true, though using this kind of macro inside of `chain` should
be an almost-nonexistent use case, provided other macros also use <> and
<...> for the same purpose (as variable placeholders). This is also a
limitation shared with SRFI 26.
> 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.)

"Procedure Call Chaining Operators" is a decent name, although it's
getting even more verbose. I think "Expression Chaining Operators" is
clear enough.

> (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.
This is sacrificing ease of use in the general case for a rare edge
case. Pipeline operators are a common feature in functional languages,
but I'm not aware of any language that has a special case to handle
pipeline calls that return void. A pipeline with a void return value in
it is not a pipeline, it's just a `begin`. This is outside the scope of
this SRFI.
> (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.
I added a test for this, thanks!
> (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)
These might be useful, but they're outside the scope of this SRFI.