Re: apparent bug in sample implementation of SRFI 148 William D Clinger (20 Jul 2017 08:23 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (21 Jul 2017 12:41 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (21 Jul 2017 18:55 UTC)
Re: apparent bug in sample implementation of SRFI 148 John Cowan (22 Jul 2017 00:14 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (22 Jul 2017 00:54 UTC)
Re: apparent bug in sample implementation of SRFI 148 John Cowan (22 Jul 2017 04:46 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (22 Jul 2017 07:45 UTC)
Re: apparent bug in sample implementation of SRFI 148 Alex Shinn (22 Jul 2017 07:17 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (22 Jul 2017 08:06 UTC)
Re: apparent bug in sample implementation of SRFI 148 Alex Shinn (22 Jul 2017 08:48 UTC)
Re: apparent bug in sample implementation of SRFI 148 Arthur A. Gleckler (22 Jul 2017 15:01 UTC)
Re: apparent bug in sample implementation of SRFI 148 Arthur A. Gleckler (24 Jul 2017 05:57 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (22 Jul 2017 09:13 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (22 Jul 2017 11:16 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (23 Jul 2017 11:18 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (23 Jul 2017 13:34 UTC)
Re: apparent bug in sample implementation of SRFI 148 Alex Shinn (24 Jul 2017 03:23 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (24 Jul 2017 03:46 UTC)
Re: apparent bug in sample implementation of SRFI 148 Al Petrofsky (24 Jul 2017 03:41 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (25 Jul 2017 00:33 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (25 Jul 2017 05:24 UTC)
Re: apparent bug in sample implementation of SRFI 148 Alex Shinn (27 Jul 2017 04:37 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (27 Jul 2017 11:57 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (24 Jul 2017 03:26 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (24 Jul 2017 06:19 UTC)

Re: apparent bug in sample implementation of SRFI 148 William D Clinger 22 Jul 2017 00:53 UTC

John Cowan wrote:

> No such change was required.  Both the R5RS and the R7RS say, in the first
> sentence of section 4.3.1, "Let-syntax and letrec-syntax are analogous to
> let and letrec, but they bind syntactic keywords to macro transformers
> instead of binding variables to locations that contain values."  Since
> nobody thinks (or I hope nobody thinks) that identifiers bound by let and
> letrec are within the existing binding contour, it follows that nobody
> ought to think that syntactic keywords bound by let-syntax and
> letrec-syntax in R[57]RS are within the existing binding contour.

Nobody is saying the syntactic keywords bound by let-syntax and letrec-syntax
are bound within any region other than the body of the let-syntax or the
entire letrec-syntax.  The R5RS, R6RS, and R7RS are all clear on that point.

That, however, is not the issue.  The question is whether new definitions
obtained via macro expansion within the body are spliced into the context
of the let-syntax or letrec-syntax.  The R5RS is silent on that point.
Several R5RS implementers had realized it was more generally useful and
at least as natural to have them spliced (as if wrapped in a begin) than
to introduce an artifical new contour (as if wrapped in a let).  The R6RS
editors, after considering the diversity of practice in R5RS systems,
decided to standardize on the splicing semantics.

As I recall, there was no real controversy about that at the time.

Because the R7RS essentially retains the R5RS prose, which said nothing
about the matter and had therefore been interpreted as allowing both the
splicing semantics and the new contour semantics, the R7RS is also being
interpreted as allowing both the splicing semantics and the new contour
semantics.

As has been pointed out to me, the WG1 archives prove that a plurality of
the WG1 members who voted on this intended to require the new contour
semantics, but the R7RS (small) document fails to do that, and the R7RS
also fails to note any change from R6RS semantics in this regard.

Will