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?