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