Future directions of the nest macro Marc Nieper-Wißkirchen (31 Aug 2020 18:12 UTC)
Re: Future directions of the nest macro Adam Nelson (01 Sep 2020 01:05 UTC)
Re: Future directions of the nest macro Marc Nieper-Wißkirchen (01 Sep 2020 06:20 UTC)
Re: Future directions of the nest macro Dr. Arne Babenhauserheide (01 Sep 2020 05:26 UTC)
Re: Future directions of the nest macro Marc Nieper-Wißkirchen (01 Sep 2020 06:05 UTC)
Re: Future directions of the nest macro Adam Nelson (01 Sep 2020 17:39 UTC)
Re: Future directions of the nest macro Marc Nieper-Wißkirchen (02 Sep 2020 07:12 UTC)

Re: Future directions of the nest macro Marc Nieper-Wißkirchen 02 Sep 2020 07:11 UTC

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

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

Linus was initially mentioning a similar macro he had written that
does non-shallow substitution, so he might be in favor of a nest that
doesn't stop at the first level.

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

Why would nesting in a let-init expression, for example, be more
niche? Or in a case-lambda body? Or in the following example

(with-exception-handler
    (lambda () ...)
  (lambda ()
   _))

where I want to replace the actual body.

PS The chain macro itself is also, in the same sense, not fully
satisfying because "_" is also only replaced at the top-level. But in
conjunction with rest arguments "_ ..." is makes sense.