Hi Wolf, Am Sa., 30. Dez. 2023 um 03:05 Uhr schrieb Wolfgang Corcoran-Mathe < [email protected]>:
> 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. Marc
