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.
The spec fails to say that s-expressions are n-expressions. For "We encourage implementations to *always* implement curly-infix expressions" read "Implementations SHOULD implement c-expressions". For "Applications should" read "Applications SHOULD". For "We recommend that portable applications do *not*" read "Applications SHOULD NOT". For "We encourage implementations' *default* invocation" read "An implementation's default implementation SHOULD", and remove ", but this is not required". As mentioned earlier, remove the sentence about "curly-foo" What is said about defining "nfx" should also be said about "$bracket-access$". For "(curly-infix-read . port)" read something like "curly-infix-read with an optional port argument. Add the following boilerplate to the top of the specification: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. I recommend the use of small capital letters rather than italics for these key words: this can be achieved in HTML with <small>MUST</small>, <small>SHOULD</small>, etc. or in HTML/CSS with <span style="font-variant: small-caps;">must</span>, etc. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@xxxxxxxx --Quentin Crisp http://www.ccil.org/~cowan