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).

I don't think that macro calls are universally supported (at least not
in the best sense of the world), so I wouldn't advertise it. The
problem is if you have a macro call that uses "<>" itself as auxiliary
syntax. It *should* shadow the "<>" of "chain", but it doesn't it.

> 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.)
>
> This may be an irreconcilable divide in how we see this SRFI. I would like this SRFI to be a small piece of syntax that users can reasonably expect to be present in every Scheme, or can easily port if it's unavailable, similar to SRFI 2 or SRFI 26. Because of this, I'd like to avoid requiring language-level optional features like syntax parameters. Don't get me wrong, syntax parameters are a great idea, and probably should have been part of R7RS to begin with. But because there are Schemes that don't support them and likely never will, and because SRFI 197 without syntax-parameters is maximally portable, I have no intention of using them.

There are also Schemes that do not support syntax-rules, so your
argument is not completely universal. :)

But I see your point and it makes sense. Therefore, I am wondering
whether we can define the syntax in such a way such that this SRFI
supports nested occurrences of "<>" whenever the underlying
implementation has a powerful enough syntax expander (possibly Guile,
Racket, Chez, Chibi). This way, we would define two implementation
levels.

That said, you don't necessarily need syntax parameters if "<>"
appears in the macro call at a position where the chain macro can
recognize it.

> There is precedent for allowing <> and <...> at only the top level, since that is how SRFI 26 cut already works.

That's true. It never occurred to me because I have never used SRFI 26
for explicit lambdas have always been much clearer to me. (For SRFI
148, it is a crucial primitive form because there is no equivalent of
lambda.)

> And, though this might be motivated reasoning from my own biases, I think there are advantages to this limitation. Any time <> occurs in a nested form, that form could be extracted into a separate step, and that is almost always a clearer way to write a pipeline.
>
> For example. this:
>
> (chain (+ (* <> 2) 1) (- 3))
>
> Can be rewritten as this, which is more idiomatic:
>
> (chain (* <> 2) (+ <> 1) (- 3))

This is not necessarily how I write mathematical formulas. :)

The example you give is trivial to rewrite. But what about:

(chain (f) (let ((x <>)) (g x x)) (h <>))

> Also, because the order of multiple <>s is significant, it needs to be clear what order they occur in; this is more difficult to tell in a nested form.

This is correct and we would have to drop the possibility of more than
"<>". But I think that this restriction (which is only relevant for
multiple values) is less severe than restricting to "<>" to top-level
expressions as we cannot permute the values anyway. So in general, we
cannot do with out permutation functions:

(chain (f) ((lambda (x y z) (values z x y)) <...>) (g))

>
> (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.)
>
> I can add that. That will also remove the need for the <...> branches of chain-and and chain-when that end in syntax-errors.

Speaking of adding things: maybe you could also add a formal syntax
section (see SRFI 26, for example). This will make the restriction to
top-level replacement and the behavior with respect to macro calls
that occur pretty obvious.

> (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.
>
> This is a conflict between practicality and conceptual purity. If the default is to append all return values to the end of each step, then each step will be called via apply, which will be slower in both compiled and interpreted Schemes unless they have extremely sophisticated static analysis capabilities. I would prefer that there is no performance cost to using chain in the most obvious, natural way.

Agreed. I am wondering whether some clever coding that could help to
optimize away the "apply", but I have currently no idea.

> (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".
>
> 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.

> (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.
>
> Yes, it allows this. There is a test case for it in test.scm. If that wasn't clear from the specification, I can add it. Perhaps it should use the term "rest argument" instead of "variadic".

Sorry, I haven't checked the tests.

> (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.
>
> This will be difficult for me, but I can give it a try. I've only been writing Scheme for about a year, and I've only learned R7RS. I haven't tried to learn syntax-case yet, but from what I've seen of it it looks much more complicated. I'll start reading about it, maybe it's easier than it looks.

As you can easily map any syntax-rules macro to a syntax-case macro,
it cannot be more complicated (unless you start to write complicated
macros not possible with syntax-rules :)).

The main point is that you can use ordinary Scheme code instead of the
recursive pattern matching magic and this should make things a lot
simpler to understand. In case you have questions and would like to
have some support, you can contact me privately.

> (7) Change your baking recipe to use the metric system. We don't live
> in the 19th century anymore. :)
>
> https://i.kym-cdn.com/photos/images/original/000/203/006/tumblr_luu1piOxNN1r1nz41.png

This is literally wearing borrowed plumes. ;)

The correct eagle is probably this one:
https://upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Flag_of_Prussia_%281466-1772%29_Lob.svg/220px-Flag_of_Prussia_%281466-1772%29_Lob.svg.png.
If I am not mistaken, Fahrenheit was born in Danzig, which was part of
Royal Prussia (Polish Prussia) at that time. :)

> But seriously, thanks for all of the help refining this SRFI, even if I haven't agreed with all the suggestions. Hopefully it's almost done! :)

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.