Mark H Weaver said:
> I recently wrote a preliminary implementation of SRFI-105 for Guile 2.0

Thanks VERY MUCH!! That's awesome.

> and found a few places where the clarity of the specification could be
> improved.

Thanks for the feedback!

>
> 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)))

Yes, that's the intent.

> 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.

You're absolutely right, we need to address that.

Alan Manuel Gloria says:
> My gut instinct is "it's still neoteric in vector literals" i.e.
> vectors in n-expression position MUST contain n-expressions.

I agree.  In fact, the sample implementation *specifically* implements neoteric-expresions within vectors, so:
 {#(1 2 f(a) 4)}
maps to:
 #(1 2 (f a) 4)

I'll modify the spec to clarify that, including that example.

Alan Manuel Gloria says:
> I think I'd also clarify that any other literals specific to an implementation
> SHOULD also support n-expressions in places that they support
> s-expressions, if the literal is in n-expression position.

Agree.  I'll add that.

Mark H Weaver said:
> 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))

Alan Manuel Gloria says:
>My gut instinct is to say "yes, datum comments should consume
>n-expressions if they are found in n-expression position".

I agree with that, too.  I'll add a note, and the example listed above.

> 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.

Okay.  I'll probably steal more examples from the test suite we have in the readable project.  There's an endless number of tests one can create, but a larger test suite combined with a hopefully clear spec is a good thing.

> Thanks for your work on this!

And thank YOU, very much, for your work.  I think SRFI-105 has to be available on many implementations to be really useful, and your work is a critical part of that.

--- David A. Wheeler