If you were considering doing this, how would you underspecify `nest` to
allow for this implementation? The only thing that occurs to me is to
forbid `_` in any non-top-level form inside a `nest`, or to call it
undefined behavior. This `nest` would also have to allow steps with no
top-level `_`, which would also be undefined behavior? This would make
using `chain`, `is`, or `match` inside `nest` impossible (without
renaming the placeholder), which seems like an unnecessary burden just
to reserve the possibility of future changes.

SRFIs have reused existing names with different behavior before (see:
the 3 different hash-table SRFIs, all of the string SRFIs). If we want
to redefine `nest` to support arbitrarily deep `_` locations, that can
be its own SRFI later. Although, in my opinion, it would make more sense
to use a more descriptive name for this macro, like `nest-deep` or
`nest/deep`.

On 8/31/20 2:11 PM, Marc Nieper-Wißkirchen wrote:
> In the current definition of the nest macro, each step has to be of
> the form (<datum> ... _ <datum> ...) and the single underscore is
> replaced by the result of the nesting the later steps.
>
> This is the best one can do if nest is supposed to be implementable
> with syntax-rules (which is, I think, the intent of SRFI 197), but it
> also limits its applicability (and may not always yield what one may
> expect).
>
> For example, the following does not work
>
> (nest
>    (let ((x _))
>      (* x x x))
>    <complicated init expression>)
>
> because nest replaces the underscore purely textually at the top-level.
>
> With a more powerful macro system, more satisfying versions of nest
> are possible:
>
> (define-syntax nest
>    (lambda (stx)
>      (syntax-case stx ()
>        ((k step init)
>         (with-syntax ((_ (datum->syntax #'k '_)))
>           #'(let-syntax ((_ (identifier-syntax init)))
>               step))))))
>
> Unfortunately, a Scheme system powerful enough so that the latter
> version can be implemented cannot ship that version together with SRFI
> 197 because it is not in all cases a conservative extension.
>
> The same holds for R7RS-large, which may get a macro system powerful
> enough, and for which it would then probably make more sense to
> standardize the latter version of nest.
>
> There are three ways to proceed:
>
> (1) Underspecify "nest" in SRFI 197 so that the latter version is
> still a faithful implementation (and so that we can write a
> conservative extension of SRFI 197 one day).
>
> (2) Call "nest" in SRFI 197 slightly different (maybe indicating that
> just the top-level is substituted), so that this sweet and short name
> is not already taken once the more satisfying version of nest becomes
> possible.
>
> (3) Stick to the name of "nest" in SRFI 197, but then we would have to
> find another natural name for the more natural latter version.
>
> Marc