On 9/1/20 2:04 AM, Marc Nieper-Wißkirchen wrote:

> Am Di., 1. Sept. 2020 um 07:26 Uhr schrieb Dr. Arne Babenhauserheide
> <xxxxxx@web.de>:
>>
>> Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:
>>
>>> 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).
>> This looks to me like another argument for splitting out nest from
>> SRFI-197 and creating a new SRFI for it. It can still be an
>> implementation detail, but it seems to strongly increase the effort for
>> optimal implementation of SRFI-197.
> Regardless of the discussion about the best version of "nest", I agree
> with Arne that it makes a lot of sense to take out nest and friends
> from this SRFI. SRFI numbers are relatively cheap, so not much is
> lost. Earlier, Arne already gave another strong argument in favor of
> splitting into two SRFIs. While "chain" and "nest" have something to
> do with what you call "pipelining", under their hood, their semantics
> are completely different and, in reality, they do everything but
> similar things.
>
> Marc

There seems to be a 50/50 split for/against this change, since Linus and
John were in favor of including `nest` in my original thread about it.
I'd still prefer to keep it, and I don't find the possibility of an
alternate `nest-deep` implementation a compelling reason to reconsider
it; that style of `nest` macro seems like an extremely niche use case.

If more people comment and are against including `nest` in this SRFI,
I'll reconsider it.