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