nest macro and final draft Adam Nelson (08 Aug 2020 14:34 UTC)
Re: nest macro and final draft Linus Björnstam (08 Aug 2020 14:59 UTC)
Re: nest macro and final draft John Cowan (09 Aug 2020 00:32 UTC)
Re: nest macro and final draft Marc Nieper-Wißkirchen (09 Aug 2020 09:36 UTC)
Re: nest macro and final draft Marc Nieper-Wißkirchen (09 Aug 2020 09:49 UTC)
Re: nest macro and final draft Linus Björnstam (09 Aug 2020 14:03 UTC)
Re: nest macro and final draft John Cowan (09 Aug 2020 16:19 UTC)

Re: nest macro and final draft Marc Nieper-Wißkirchen 09 Aug 2020 09:35 UTC

A possible problem with the "nest" macro is that it doesn't respect
scoping of "<>", does it? To me it looks as if one cannot nest (no pun
intended) a nest in a nest.

Unless a good, convincing and sound solution will be found, I wouldn't
add it to this SRFI. Once good semantics of "nest" have been found, we
can easily create a new SRFI. In any case, this is probably a good
idea because "nest" does really something different than "chain".

Marc

Am So., 9. Aug. 2020 um 02:33 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> +1
>
> On Sat, Aug 8, 2020 at 10:59 AM Linus Björnstam <xxxxxx@veryfast.biz> wrote:
>>
>> I have had a nest macro in my repl prelude for 10 years and use it several times a week.
>>
>> I think it is within the scope of this SRFI and even though it sort of represents what I firmly put in the category "ugly things I believe common lispers like" I think it has utility and should be included since it can be done in a clean enough way.
>>
>> --
>>   Linus Björnstam
>>
>> On Sat, 8 Aug 2020, at 16:34, Adam Nelson wrote:
>> > It's been a while since we've discussed SRFI 197. I think the current
>> > draft could work as a final draft, since we haven't decided on any
>> > specific changes or new features (that I remember), and SRFI 197 is
>> > simple anyway.
>> >
>> > There is one new feature that I've been considering adding. I found a
>> > need for it while writing my implementation of `match` in Schemepunk.
>> >
>> > `(chain a (b) (c))` is equivalent to `(let* ((x (b a)) (x (c x))) x)`,
>> > not `(c (b a))`. This is intentional, because `chain` should enforce
>> > evaluation order. But it doesn't allow nesting of macros or special
>> > forms.
>> >
>> > I'm considering adding two new macros, `nest` and `nest-reverse`. These
>> > work like `->>` used to, literally nesting expressions, without using
>> > `let*`. `nest-reverse` nests in the same order as `chain` (deepest item
>> > first), while `nest` preserves syntax order (deepest item last). They
>> > both support `<>`, but do not support multiple `<>`s or `<...>`.
>> >
>> > As an example of how they would work, this code:
>> >
>> >     (if x
>> >       (parameterize ((y x))
>> >         (with-output-to-string
>> >           (lambda ()
>> >             (display y))))
>> >       (error "kaboom"))
>> > Can be rewritten with `nest` like this:
>> >
>> >     (nest
>> >       (if x <> (error "kaboom"))
>> >       (parameterize ((y x)))
>> >       (with-output-to-string)
>> >       (lambda ())
>> >       (display y))
>> > `nest` is particularly useful for converting a `...` expansion in a
>> > `syntax-rules` macro into a nested expression.
>> >
>> > Thoughts? I'm still undecided on adding this to SRFI 197.
>> >