apparent bug in sample implementation of SRFI 148 William D Clinger (18 Jul 2017 17:17 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (18 Jul 2017 19:01 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (18 Jul 2017 20:53 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (18 Jul 2017 23:33 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (19 Jul 2017 12:36 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (19 Jul 2017 13:41 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (19 Jul 2017 14:09 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (19 Jul 2017 14:27 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (19 Jul 2017 15:42 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (19 Jul 2017 17:34 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (19 Jul 2017 20:31 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (19 Jul 2017 21:07 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (20 Jul 2017 01:22 UTC)
Re: apparent bug in sample implementation of SRFI 148 William D Clinger (20 Jul 2017 01:37 UTC)
(missing)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (20 Jul 2017 08:01 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (20 Jul 2017 12:53 UTC)
Re: apparent bug in sample implementation of SRFI 148 Al Petrofsky (20 Jul 2017 23:06 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (21 Jul 2017 08:16 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (21 Jul 2017 13:13 UTC)
Re: apparent bug in sample implementation of SRFI 148 Alex Shinn (22 Jul 2017 10:53 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (22 Jul 2017 10:59 UTC)
Re: apparent bug in sample implementation of SRFI 148 Alex Shinn (22 Jul 2017 11:11 UTC)
Re: apparent bug in sample implementation of SRFI 148 Marc Nieper-Wißkirchen (20 Jul 2017 05:44 UTC)
Re: apparent bug in sample implementation of SRFI 148 Takashi Kato (20 Jul 2017 06:48 UTC)

apparent bug in sample implementation of SRFI 148 William D Clinger 18 Jul 2017 17:17 UTC

It looks to me as though the sample implementations of SRFI 147
and/or SRFI 148 are relying on non-portable behavior by the native
macro system.  In the following example, I will ignore hygienic
renamings because the problem has mainly to do with structure, not
hygiene.

Consider the following example, which is part of the first test
in the test program for SRFI 148.

(let-syntax ((m
              (em-syntax-rules ()
                               ((m 'a) 'a))))
  (m '(define x 10))
  x)

To find the boundary between definitions and expressions, it
is necessary to expand the (em-syntax-rules () ((m 'a) 'a))
part, which turns into something like

(em-syntax-rules-aux1
  free-identifier=?
  ()
  ...
  ()
  (((m 'a) 'a)))

which turns into something like

(em-syntax-rules-aux2
  free-identifier=?
  ()
  ...
  ()
  (((m 'a) 'a)))

which turns into something like

(begin
  (define-syntax
    o
    (em-syntax-rules-aux2
      o
      free-identifier=?
      ()
      ...
      ()
      (((m 'a) 'a))
      ()))
  o)

That is not legal in R7RS (small).  You can't use a macro
keyword as though it were an expression.

SRFI 147 extends R7RS (small) by allowing macro keywords to
be used in certain contexts, but the sample implementation of
SRFI 147 does not export the begin keyword, so begin has its
usual R7RS (small) meaning in libraries that import (srfi 147).

In particular, the "begin" introduced by the em-syntax-rules-aux2
macro of the sample implementation of SRFI 148 has its usual R7RS
(small) meaning, so that macro doesn't work in systems that check
for the error of using a syntactic keyword as though it were an
expression.

Whether this should be regarded as an error in the sample
implementation of SRFI 147 or SRFI 148 or both may be unclear,
but it seems pretty clear that the result of combining those
two sample implementations is not portable R7RS (small) code.

Will