I really wasn't wanting to make this change because it complicates the
definitions of every "chain" macro and makes the implementation much
more elaborate (the syntax-rules definition of nest involves generating
a new let-syntax macro definition with the placeholder), but I
understand that there are some cases where it could be used. And it adds
some symmetry to chain and nest.

I don't think a warning is necessary; there's nothing about the way
chain uses keywords that is any different from the way any other macro
uses keywords, so this is a universal hygiene issue in Scheme. And SQL
injection isn't a fair comparison. You should never be passing
user-provided data into the macro expander at runtime; if you're doing
that, you have bigger problems.

I appreciate all of the feedback on this SRFI, and it's really helped me
refine it into something more sophisticated than a simple port of a
Clojure feature, but it's reaching a point that I can't keep making
changes and debating them and dragging this out. When I make this change
I intend for this to be the final version of SRFI 197. I don't want to
add or remove any more features; I have a lot of other projects going
on, and even other SRFI ideas, and this SRFI process has taken much
longer than I expected it to. I will submit the next version as draft 5
for proofreading, but I intend to move it to final within a few days.

On 9/2/20 3:26 AM, Marc Nieper-Wißkirchen wrote:
> I know that I responded to John that the chain macros do not need to
> allow a custom placeholder.
>
> Well, that's true until you want to use the chain macros in other
> macros that work on user code:
>
> (define-syntax chain-using-macro
>    (syntax-rules
>      ((chain-using-macro temp)
>       (chain bowl (add eggs _) (bake/kelvin _ temp)))))
>
> Looks good? Unfortunately, it can fail in some instances (for
> simplicity, I assume that _ is bound to a syntax parameter in (scheme
> base), which is allowed; otherwise my example would have to be a bit
> more complicated):
>
> (syntax-parameterize ((_ (identifier-syntax 420)))
>    (chain-using-macro _))
>
> We see that the chain-using-macro leaks some internals, something
> hygiene should have prevented us from. The same problem holds for the
> nest macro, of course.
>
> This can and should be prevented by adding a custom placeholder to the
> chain macro. And a warning should be added, namely that the chain and
> the nest macro should never be used on user-provided code unless a
> custom placeholder is specified. We don't need to replicate SQL
> injections. :)
>
> Marc
>
> Am Mo., 31. Aug. 2020 um 19:28 Uhr schrieb Marc Nieper-Wißkirchen
> <xxxxxx@nieper-wisskirchen.de>:
>> Am Mo., 31. Aug. 2020 um 19:01 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>>> I can't actually think of an example where nested `nest` would be used. I used that as the justification for the placeholder parameter because you mentioned it in a previous email thread:
>>>
>>> https://srfi-email.schemers.org/srfi-197/msg/15006221/
>>>
>>>> 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.
>> When I wrote this, I momentarily had the idea that nest would replace
>> the underscore throughout the whole s-expression at not only at
>> top-level.
>>
>>> There is a practical use for this placeholder, though. I use `nest` to define the `or` and `and` patterns in Schemepunk's SRFI-204-like `match`. The macro could generate a `nest` step with an underscore symbol (as a `match` pattern), even though that underscore is not meant as a placeholder. Importing _ under a different name doesn't work, since nest's _ and match's _ are the same identifier. So it needs an alternate placeholder.
>> Thanks! That makes perfect sense. May I suggest that you add this
>> practical use as a rationale for specifying the "_" explicitly?