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.
John Cowan: ... > For "We encourage implementations to *always* implement curly-infix > expressions" read "Implementations SHOULD implement c-expressions". Done. > For "Applications should" read "Applications SHOULD". Waiting to see if there are other comments on the MUST/SHOULD markers. > For "We recommend that portable applications do *not*" read "Applications > SHOULD NOT". Done. > For "We encourage implementations' *default* invocation" read "An > implementation's default implementation SHOULD", and remove ", but this > is not required". Done. > As mentioned earlier, remove the sentence about "curly-foo" Plan to; want to see if there are other comments. > What is said about defining "nfx" should also be said about > "$bracket-access$". Done. > For "(curly-infix-read . port)" read something like "curly-infix-read > with an optional port argument. Done. I used [port] instead of ". port". > 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. Done. > 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. Currently leaning towards <em>SHOULD</em> instead of <small>...</small>, due to concerns about what <small> might do, but I'm curious what others say. --- David A. Wheeler