OK, there is a new document up that I hope to finalize within the next
day.  Any further comments should be sent by tomorrow at around 16.00
EST.

On Fri, 29 Oct 2004, Algebraic Pentameter Petrofsky wrote:

> At http://petrofsky.org/src I've put an updated version of EIOD that
> supports the SRFI-46 draft.  At the same location you can find
> alexpander, which also supports the current draft.

Thanks, I've added this to the document and directory.

> Some comments on the SRFI:
>
>   ELLIPSIS-IDENTIFIER specifies the token used for ellipsis.  ... This
>   identifier, when generated by macros, is subject to the usual rules
>   of hygiene.
>
> [...]
>
> These "usual rules" don't say anything about ellipses.  I think the
> minimal way to state what you are getting at (assuming that what you
> are trying to say is what I implemented) is something like this:
>
>   When an ellipsis identifier is specified, that specification is
>   considered a binding whose scope is the rules of the transformer.
>   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.

> 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.

> 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.

> At the end of the SRFI:
>
>   There is no 'official' reference implementation here provided,
>   because this SRFI defines an extension to existing macro expanders,
>   which all vary vastly in implementation.
>
> I think you mean to say that it is impractical to provide a widely
> ready-to-use implementation.

Correct.  I have changed the text to reflect this.

>   Al* Petrofsky suggested that there still be here provided some
>   examples of macro expanders that have been modified to support these
>   extensions already;
>
> Right, and that's what reference implementations are: implementations
> to which people can refer when implementing the specification.

...and to reflect this.  Is there anything else you'd like me to add on
the matter of the reference implementations?