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

Cleaning up SRFI 105 MUSTard (mostly)

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