Email list hosting service & mailing list manager

Why splicing syntax? Duy Nguyen (27 Mar 2020 08:17 UTC)
Re: Why splicing syntax? Marc Nieper-Wißkirchen (27 Mar 2020 08:25 UTC)
Re: Why splicing syntax? Arthur A. Gleckler (28 Mar 2020 05:02 UTC)
Re: Why splicing syntax? Duy Nguyen (30 Mar 2020 08:19 UTC)
Re: Why splicing syntax? Marc Nieper-Wißkirchen (30 Mar 2020 08:41 UTC)
Re: Why splicing syntax? John Cowan (30 Mar 2020 14:31 UTC)
Re: Why splicing syntax? Marc Nieper-Wißkirchen (30 Mar 2020 14:45 UTC)
Re: Why splicing syntax? John Cowan (30 Mar 2020 15:30 UTC)
Re: Why splicing syntax? Duy Nguyen (31 Mar 2020 10:05 UTC)

Re: Why splicing syntax? Duy Nguyen 31 Mar 2020 10:05 UTC

On Mon, Mar 30, 2020 at 3:41 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>> Maybe you could expand a bit on the rationale though. Even with that
>> fix my thinking was "so it helps reduce one macro (em), big deal". I
>> didn't follow Scheme development closely (and completely ignored
>> scheme while r6rs was developed) maybe that's why I just don't see why
>> it's non-controversal as others do. I could understand if this is an
>> effort to bring back a feature from r6rs and somewhat unify the two
>> standards.
>
>
> Thanks for your comments. This SRFI is less about unifying the two standards but to add a binding construct for syntactic keywords that is so far missing in R7RS and will help macro writers. That said, with SRFI 188, it will be easier to port some R6RS or Racket programs to R7RS. Many Schemes implementing R7RS already include a splicing binding construct for syntactic keywords so one main point of this SRFI is to standardize names for these splicing binding constructs.
>
> [snipped]

Thanks. It definitely helps.
--
Duy