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 01 Sep 2020 06:04 UTC

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