Am Mo., 30. März 2020 um 16:31 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
Just to put myself on record, I voted against the proposal to make let-syntax non-splicing because I misunderstood it as saying that the *macro name* should be spliced into its context, which obviously violates the contract of let-*.  If I had understood, I might have voted for it.

Thanks for chiming in.  Do you have any favorite among the proposed names?
 
On the other hand, I think it is a good principle not to make silent breaking changes to existing standards, as R6RS did with real? and its subpredicates.  In R6RS a complex number whose imaginary part is an inexact zero is not considered a real number, and while I understand the logic behind this, it can cause existing code to stop working without explanation.  The reason I have not proposed an R6RS-compatible version is partly because no one can think of a non-confusing name: R6RS has real? for the modified version and real-valued? for the R5RS-compatible version, which is already confusing.

Actually, the R7RS adopted at least one silent (breaking?) change of the R6RS, namely the semantics of internal defines. In R5RS, these defines were explained through `letrec', in R6RS and R7RS through `letrec*'. (Technically, the decision of WG 1 was the right one, for sure.)
(Just for the record, this SRFI is not about any breaking change to R7RS, but to have a standardized name for an addition to R7RS, which is already implemented by many Schemes under different names.)

--

Marc

P.S.: Incidentally, Chibi, which was probably the first full R7RS implementation, has implemented the R6RS and not the R5RS semantics of `let-syntax' and `letrec-syntax'.
 

On Mon, Mar 30, 2020 at 4:41 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
Am Mo., 30. März 2020 um 10:19 Uhr schrieb Duy Nguyen <xxxxxx@gmail.com>:
On Fri, Mar 27, 2020 at 3:25 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
>
>
> Am Fr., 27. März 2020 um 09:17 Uhr schrieb Duy Nguyen <xxxxxx@gmail.com>:
>>
>> This may be a dumb question but what does splicing syntax give?
>
>
> It's not a dumb question; it was a stupid mistake on my side.

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.

The non-splicing binding constructs `let-syntax' and `letrec-syntax' as provided by R7RS are somewhat superfluous because they give the macro programmer nothing that cannot be expressed with `define-syntax'.

On the other hand, there are some macros that can only be expressed with the splicing versions.  The simplest example is a macro `foo' that is supposed to transform one form into another one and that needs to define an auxiliary macro `aux' (depending on its own parameters):

(define-syntax foo
  (syntax-rules ()
    ((foo form)
     (begin
       (define-syntax aux (syntax-rules () (... form ...)))
       (... aux ... form ...)))))

This macro has to be used in a definition context because it expands into an instance of `define-syntax' and more.  If you want to use the very same macro in an expression context, you have to rewrite it:

(define-syntax foo
  (syntax-rules ()
    ((foo form)
      (let-syntax ((aux (syntax-rules () (... form ...))))
        (... aux ... form ...)))))

That's unpleasant and maybe hard to understand for the user. With `splicing-let-syntax', one macro suffices:

(define-syntax foo
  (syntax-rules ()
    ((foo form)
      (splicing-let-syntax ((aux (syntax-rules () (... form ...))))
        (... aux ... form ...)))))

From a theoretical point of view, there is no reason why binding constructs for syntactic keywords should not be splicing, that is, why they should not have the same semantics as `begin'.

Does this help?

Marc