Re: Suggestions and EIOD update campbell@xxxxxx 07 Nov 2004 17:30 UTC
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?