On Sun, 7 Nov 2004, Alcoholic Petrofsky wrote:

> The eiod-based reference implementation says:
>
>   ;; eiod.scm: eval-in-one-define
>   ;; $Id: eiod.scm,v 1.2 2004/11/07 17:32:23 campbell Exp $
>
> If you want to add your own version information, that's fine, but
> please do not put anything out on the net that only identifies itself
> as eiod 1.2, unless it is the petrofsky.org eiod 1.2, which is dated
> 2002/05/21 and is quite different from what you have there.  I suggest
> you add something like this:
>
>   ;; The rest of this file is eiod.scm version 1.16 from
>   ;; http://petrofsky.org/src

Whoa!  Sorry, I didn't even notice the RCS tag junk when I committed it
to srfi.schemers.org -- the updating of it was automatic and completely
beyond my notice.  I'll fix that immediately.

Please make a similar change in alexpander (also, I suggest you fetch
> a more recent version of alexpander).

...and that too.

> xxxxxx@autodrip.bloodandcoffee.net wrote in message
> <Pine.LNX.4.44.0411070951080.1365-100000@autodrip.bloodandcoffee.net>
> (which doesn't seem to have made it to schemers.org yet, but of which
> I received a carbon copy)

Yes, my SRFI subscriptions are *really* screwed up.  I pestered the
editors about it a little while ago, but to very little noticeable
effect.  I never remember which SRFI lists I'm still subscribed to, so
I just Cc them anyway and hope someone notices the email.

> > >   ... The macro system must make the usual hygienic arrangements
> > >   to preserve the lexical scoping of these bindings.
> >
> > OK, I've changed the text to look a bit more like this.
>
> Draft 1.3 says:
>
>   ... The macro system implementation must make usual hygienic
>   arrangements to preserve & protect the lexical scope of these
>   bindings.
>
> I think "usual" needs to be "the usual" or "its usual".  Perhaps
> better would be "... must make the hygienic arrangements described in
> r5rs section 4.3 to preserve ...".

OK, I shall specify that further.

> > > Here's an example you could use, whose result depends on whether or
> > > not F inserts the binding for ::: hygienicly:
> > >
> > >   (let-syntax
> > >       ((f (syntax-rules ()
> > > 	    ((f e)
> > > 	     (let-syntax
> > > 		 ((g (syntax-rules ::: ()
> > > 		       ((g (x e) (y :::))
> > > 			'((x) e (y) :::)))))
> > > 	       (g (1 2) (3 4)))))))
> > >     (f :::))
> > >   => ((1) 2 (3) (4))    [ rather than ((1) (2) (3) (4)) ]
> >
> > I have added this example.
>
> You added it like this:
>
>   (let-syntax
>       ((f (syntax-rules ()
> 	    ((f ?e)
> 	     (let-syntax
> 		 ((g (syntax-rules ::: ()
> 		       ((g (??x ?e) (??y :::))
> 			'((??x) ?e (??y :::))))))
> 	       (g (1 2) (3 4)))))))
>     (f :::))
>
>       ; => ((1) 2 (3 4)), if hygienic rules of ellipsis identifiers are
>       ;      correctly implemented, not ((1) (2) (3) (4))
>
> You need to change that to "not ((1) (2) (3 4))", or (preferably) to
> follow my example more closely and change '((??x) ?e (??y :::)) to
> '((??x) ?e (??y) :::) and change "=> ((1) 2 (3 4))" to "=> ((1) 2 (3)
> (4))".

Whoops.  I suspect that the opium I consumed earlier today for lunch
dessert in the form of bearclaw-related foods may have something to do
with this confusion.  I'll fix this, too.

> I think the "tail patterns" feature would also benefit from at least
> > > one example expression, which should explicitly include the
concrete
> > > result you expect.  Here's one:
> > >
> > >   (let-syntax
> > >       ((foo (syntax-rules ()
> > > 	      ((foo x y ... z) (list x (list y ...) z)))))
> > >     (foo 1 2 3 4 5))
> > >   => (1 (2 3 4) 5)
> >
> > I think this example isn't really necessary; there already is one --
> > FAKE-BEGIN -- which I think suffices.
>
> I like the expanded discussion of fake-begin, but I still think you
> should have *at least* one example in the r5rs 1.3.4 format of
> "<expression> => <value>", which allows people to cut and paste
> <expression> into a repl and see <value> printed, and also allows them
> to easily add the expression (equal? <expression> '<value>) to a test
> suite and expect it to evaluate to #t.

OK, very well, I'll add that.

After all these changes you have made to the SRFI, Al*, at both the
levels of fundamental design and written content, I think you really
deserve to be noted as one of the SRFI's authors; after all, I just
started the SRFI and wrote some text, whereas you changed the main body
of the SRFI to be CYOE and rewrote much of the significant text -- do
you agree, and would you mind if I update the document to reflect this?