Am Di., 1. Sept. 2020 um 03:05 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:

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

Yes, you would have to use a custom placeholder for portable code with
a chain inside a nest. Rightly so! That is actually a very good thing
also for readability. The current semantics of nest is all that
syntax-rules can give us, but they are neither obvious nor natural. So
being explicit is much better here.

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

It's true that we already have different things under the same name.
But we shouldn't ask for it and knowingly run our head against a wall.

If we still want to do that, putting nest in its own SRFI would help
because then we can switch that SRFI independent of chain.

As for nest vs nest-deep, the conceptionally simpler and semantically
more satisfying version should receive the simplest name. Thus, a way
out would be to name SRFI 197's nest "nest-shallow" (or "nest*" or
something better). This also helps against any obvious
misinterpretation.

Marc