[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestions and EIOD update
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
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:
> ((f (syntax-rules ()
> ((f e)
> ((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:
> ((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?