Email list hosting service & mailing list manager

SRFI 149 is inconsistent with Al Petrofsky's examples William D Clinger (13 Jul 2017 12:42 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Marc Nieper-Wißkirchen (14 Jul 2017 09:44 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Marc Nieper-Wißkirchen (14 Jul 2017 10:20 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples William D Clinger (14 Jul 2017 17:10 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Marc Nieper-Wißkirchen (14 Jul 2017 20:01 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples William D Clinger (15 Jul 2017 00:55 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Marc Nieper-Wißkirchen (15 Jul 2017 10:23 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples William D Clinger (15 Jul 2017 11:17 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Marc Nieper-Wißkirchen (15 Jul 2017 12:26 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Arthur A. Gleckler (15 Jul 2017 18:47 UTC)
Re: SRFI 149 is inconsistent with Al Petrofsky's examples Marc Nieper-Wißkirchen (16 Jul 2017 13:10 UTC)

SRFI 149 is inconsistent with Al Petrofsky's examples William D Clinger 13 Jul 2017 12:42 UTC

I apologize for noticing this only after SRFI 149 has become final.
If the SRFI document is in error, it will be too late to fix it,
but we can at least discuss whether the SRFI document really meant
to say what it says.

On 9 March, Al-Pastor Petrofsky posted the following example:

> Suppose you have a macro that takes a list of axis names and a set of
> coordinates, and it expands to a list with each coordinate labeled
> with its axis:
>
> (define-syntax foo
>   (syntax-rules ()
>     ((foo (axis ...) (coordinate ...))
>      '((axis coordinate) ...))))
> (foo (x y) (0 0))
> => ((x 0) (y 0))
>
> And suppose you extend that macro to allow multiple sets of
> coordinates to be labeled:
>
> (define-syntax foo2
>   (syntax-rules ()
>     ((foo2 (axis ...) (coordinate ...) ...)
>      '(((axis coordinate) ...) ...))))
>
> (foo2 (x y) (0 0) (0 3))
> => (((x 0) (y 0))
>     ((x 0) (y 3)))
>
> (foo2 (x y) (0 0) (0 3) (3 4))
> => (((x 0) (y 0))
>     ((x 0) (y 3))
>     ((x 3) (y 4)))

All of those examples work as shown in Larceny, and have been working
as shown for a long time.  (That is one of the reasons I haven't been
paying much attention to SRFI 149 --- I thought it was describing a
semantics Larceny had implemented years ago.)

As Al Petrofsky pointed out, those examples are unlikely to work in
the sample implementation, and indeed those examples do not work as
shown in Chibi 0.7.3, Kawa 2.4, or Sagittarius 0.8.4.  Those three
systems "unexpectedly expand" the last two examples in the undesirable
way Al Petrofsky described, except Chibi delivers what I consider to
be an incorrect result for the last example instead of blowing up as
Kawa and Sagittarius do.

My question is whether SRFI 149 was intended to describe a semantics
in which Petrofsky's foo2 example works, or was intended to describe
a semantics in which the foo2 example doesn't work.

If SRFI 149 was intended to describe a semantics in which the foo2
example doesn't work, then there don't appear to be any motivating
examples for SRFI 149 and I won't be implementing it for Larceny
because it would break desirable macros such as foo2.

If SRFI 149 was intended to describe a semantics in which the foo2
example works as expected by Petrofsky and myself, then its

 (let-syntax
     ((foo
      (syntax-rules ()
        ((foo (a b ...) ...) '(((a b) ...) ...)))))
   (foo (bar 1 2) (baz 3 4)))

example should evaluate to (((bar 1) (baz 2)) ((bar 3) (baz 4))),
as it has been doing in Larceny for several years, not to the
result stated in SRFI 149.

Will