This page is part of the web mail archives of SRFI 46 from before July 7th, 2015. The new archives for SRFI 46 contain all messages, not just those from before July 7th, 2015.
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?