Am Sa., 15. Aug. 2020 um 18:48 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:

> Moreover, SRFI 156 already uses "_" as a placeholder. So I think you
> are almost free about the choice when it comes to consistency. :-) And
> in this case, IMHO I would choose the simplest, namely "_" and "_
> ...".
>
> Hmm... that's also a good point, I was unfamiliar with SRFI 156, but apparently there is precedent for using `_`. That's unfortunate, though, because it means `cut` will always look out-of-place...

SRFI 26 is not (yet?) part of any standard, so we can always amend it
through a new SRFI if this consistency is really required. The author
of SRFI 156 didn't want to use "<>", probably out of reasons of
readability.

> PS: For your nest macros, the placeholder has a similar status like
> the ellipsis in syntax-rules. In order to allow to nest nest macros,
> please add an optional placeholder parameter to the nest macros just
> as SRFI 46 does for syntax-rules. For the standard placeholder, you
> need the free-identifier=? equality test; for an optional one, you
> probably need the bound-identifier=? equality test.
>
> This is a good idea for both `nest` and `chain`. I can add an extra case to all SRFI 197 macros that, if the second argument is a symbol, that symbol becomes the argument-placeholder symbol.
>
>     (chain x $ (+ y $) (- $ z)) ;=> (chain x (+ y _) (- _ z))

Is this really needed for "chain"? The expressions with parentheses
are procedure calls so no direct applications of chain.

> I could also allow another symbol argument after this one, to replace `...`.

Good catch. But really needed (see above)?

> (The Gerbil Scheme implementation is going to be a huge hassle, since `_` and `...` are both reserved symbols at the reader level, and can only be detected with predicates...)

I think it would be best if such a thing is corrected by the author of Gerbil.