In favor of explicit argument Shiro Kawai (09 Aug 2020 01:33 UTC)
Re: In favor of explicit argument Lassi Kortela (09 Aug 2020 06:46 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (09 Aug 2020 09:27 UTC)
Re: In favor of explicit argument Adam Nelson (10 Aug 2020 22:25 UTC)
Re: In favor of explicit argument Shiro Kawai (10 Aug 2020 23:46 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (11 Aug 2020 07:58 UTC)
Re: In favor of explicit argument Alex Shinn (11 Aug 2020 01:29 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (11 Aug 2020 07:17 UTC)
Re: In favor of explicit argument Jim Rees (11 Aug 2020 16:45 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (11 Aug 2020 16:57 UTC)
Re: In favor of explicit argument Alex Shinn (12 Aug 2020 02:20 UTC)
Re: In favor of explicit argument John Cowan (12 Aug 2020 02:49 UTC)
Re: In favor of explicit argument Arthur A. Gleckler (12 Aug 2020 03:23 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (12 Aug 2020 13:29 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (12 Aug 2020 19:46 UTC)
Re: In favor of explicit argument Alex Shinn (13 Aug 2020 00:40 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (13 Aug 2020 07:18 UTC)
Re: In favor of explicit argument Alex Shinn (14 Aug 2020 01:24 UTC)
Re: In favor of explicit argument Adam Nelson (13 Aug 2020 01:13 UTC)
Re: In favor of explicit argument John Cowan (13 Aug 2020 01:53 UTC)
Re: In favor of explicit argument Adam Nelson (13 Aug 2020 03:09 UTC)
Re: In favor of explicit argument Alex Shinn (13 Aug 2020 03:16 UTC)
Re: In favor of explicit argument John Cowan (13 Aug 2020 03:31 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (13 Aug 2020 08:04 UTC)
Re: In favor of explicit argument Jim Rees (13 Aug 2020 18:24 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (13 Aug 2020 20:05 UTC)
Re: In favor of explicit argument John Cowan (14 Aug 2020 02:41 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (14 Aug 2020 06:34 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (14 Aug 2020 13:30 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (14 Aug 2020 14:08 UTC)
Re: In favor of explicit argument Alex Shinn (15 Aug 2020 22:56 UTC)
Re: In favor of explicit argument Marc Nieper-Wißkirchen (16 Aug 2020 07:55 UTC)
Re: In favor of explicit argument Alex Shinn (14 Aug 2020 02:29 UTC)

Re: In favor of explicit argument Marc Nieper-Wißkirchen 14 Aug 2020 14:08 UTC
Dear Arthur,

Please find attached the first draft for SRFI 206: Auxiliary Syntax Keywords.

Compared to the pre-draft here, I have improved the language after
John's suggestions so that, hopefully, no more confusion arises. As
always, feedback is welcome.

Marc

Am Fr., 14. Aug. 2020 um 15:29 Uhr schrieb Marc Nieper-Wißkirchen

<xxxxxx@nieper-wisskirchen.de>:
>
> PS One more argument for "define-auxiliary-syntax" is that it is the
> more primitive construct vs. the magic module. Some later SRFI may
> specify a general mechanism how to user-define auto-generated modules
> (like the cxr or the auto module). In this case, the library (srfi 206
> *) could be implemented through this mechanism and the primitive
> "define-auxiliary-syntax". I think this is very much in line with the
> Scheme philosophy.
>
> (And for a general adapter macro translating between symbol keywords
> to hygienic keywords in the sense of SRFI 177, we need the local
> "define-auxiliary-syntax" anyway.)
>
> Am Fr., 14. Aug. 2020 um 08:33 Uhr schrieb Marc Nieper-Wißkirchen
> <xxxxxx@nieper-wisskirchen.de>:
> >
> > John, thank you very much for your comments.
> >
> > Am Fr., 14. Aug. 2020 um 04:41 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
> >
> > > Suddenly you are talking about *equal* bindings, but until now (and in R[67]RS) it's about the bindings being the *same binding*.  That is, bound in one library (foo) and imported directly or indirectly from (foo) in all other libraries that use it.  Importing two libraries with *distinct* bindings is an error and is usually reported either by signaling an error or by reporting a warning.  It is not enough that the bindings are verbally identifiable: if (foo) defines `plus` with (define plus +) and (bar) does the same, then it is impossible to import both (foo) and (bar), because `plus` does not have the same binding in the two libraries.
> >
> > Technically, we are talking about equivalence in the sense of
> > "free-identifier=?" of the appendix to R4RS and the R6RS standard
> > libraries. I wanted to avoid this term, so I wrote just "equal
> > binding" (in the sense of "same binding") but I will amend this as it
> > obviously led to confusion.
> >
> > So, we are not inventing a third identifier equivalence (besides
> > "free-identifier=?" and "bound-identifier=?") here, but we are just
> > talking about the former. As you write, identifiers whose bindings
> > refer to different locations, where just the stored values are
> > equivalent (in the sense of "eq?", "eqv?" or "equal?") are not
> > interesting.
> >
> > > This is why the (auto) library is good whereas the define-auxiliary-syntax macro is bad.  The library provides a single binding that all other libraries can import, and exactly how it is bound isn't important.  We have shown that it can be done with a simple syntax-rules definition, and anything fancier is just gravy.  Define-aux-syntax, though, attempts to introduce a novel (and unnecessary) notion of *equal* bindings, and should be left out altogether.
> >
> > This point does not apply as no novel equality is introduced here. I
> > am sorry for the confusion and will amend the document accordingly.
> >
> > Actually, introducing the same binding (in the sense of
> > "free-identifier=?") is nothing novel. Chez, for example, has the
> > "alias" form, which exactly does this, namely giving an identifier the
> > same binding as an existing identifier in scope. (It's a nice feature,
> > which I have already used.)
> >
> > Operationally, in the expander model of Dybvig, two bound identifiers
> > are "free-identifier=?" if and only if they have the same label.
> >
> > I hope this explanation helps to see that the local binding form
> > "define-auxiliary-syntax" does no more magic than a local import of
> > the magic "auto" library would do.