[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A few requests for clarification

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.



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