This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
Hello all, I recently wrote a preliminary implementation of SRFI-105 for Guile 2.0 and found a few places where the clarity of the specification could be improved. First, the definition of neoteric expressions states that they "recurse within lists, so lists contains sequences of zero or more neoteric expressions, not s-expressions." I take this to mean that: { (f (g h(x))) } ---> (f (g (h x))) NOT (f (g h (x))) However, it does not clarify whether neoteric expressions recurse within vector literals: { (f #(g h(x))) } ---> (f #(g (h x))) OR (f #(g h (x))) ?? The same question will arise for any other kind of literal that supports symbolic elements, such a record literals or hash-table literals, for implementations that support them. Although I would not expect this SRFI to impose requirements for handling on non-standard literals, it might still be helpful to make recommendations to encourage uniformity among implementations. * * * * * * Another issue I ran into relates to datum comments of the form: #;<whitespace><datum> as specified in the R6RS and R7RS (draft 6). What kind of syntax should be used to parse <datum> within such a comment? I think it's fairly clear that <datum> should be parsed the same way as it would have been if the "#;" was removed. It would be good to add a note and an example to clarify this. For example: { (f #;g(x) h(x)) } ---> (f (h x)) NOT (f (x) (h x)) * * * * * * Finally, and perhaps most importantly, I would strongly encourage you to add many more examples (along with their s-expression equivalents) to cover every supported syntax, including all of the edge cases that implementors might conceivably get wrong. This would not only help readers clearly understand the spec, but also help ensure that SRFI-105 syntax is read the same way by all implementations. If slightly incompatible implementations became widely deployed, it could be disastrous for adoption of SRFI-105. Thanks for your work on this! Mark