Hi again,
I noticed that the SRFI's Specification section says that "An
(⟨unquote-splicing [sic] ⟨expression⟩ …) form is equivalent to
(⟨unquote⟩ ⟨expression⟩ …) ⟨ellipsis⟩". This is not true, however,
when unquote-splicing occurs in a (⟨ellipsis⟩ ⟨template⟩) form,
i.e. when ellipses are escaped. At the very least, you can't
simply translate unquote-splicing to ellipsis patterns without
checking for escapes. To avoid possible implementation bugs, I think
"... except when the unquote-splicing form occurs as a sub-template
of a (⟨ellipsis⟩ ⟨template⟩) form," or something like that, should
be appended to the sentence quoted above.
Thank you for this comment; what I meant was that in the translation, <ellipsis> had its original meaning so that unquote-splicing would work the same way, whether wrapped in (<ellipsis> ...) or not. I am going to ask Arthur to add a post-finalization not to make this clear.
There's a slightly annoying asymmetry between ellipsis patterns and
unquote-splicing. They do very similar things, but are different in
minor ways. The ellipsis identifier can be escaped in a template, but
there's no similar escape for unquote-splicing. While it's outside the
scope of this (finished) SRFI, I wonder whether another quasiquotation
form with ellipsis patterns and *without* unquote-splicing could be
more elegant. Of course, it wouldn't be as convenient. Food for
thought, I guess.
I would like the ellipsis-aware quasiquotation to be more or less a drop-in replacement for the RnRS quasiquotation so that a future report may use this in place; it is always almost more convenient.
P.S. There's also a missing bracket after "unquote-splicing" in
the sentence about ellipsis/unquote-splicing equivalence.
I think the formatting has to be fixed even more.