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

Re: Cleaning up SRFI 105 MUSTard (mostly)

John Cowan:
> For "We encourage implementations to *always* implement curly-infix
> expressions" read "Implementations SHOULD implement c-expressions".


> 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


> 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"

Plan to; want to see if there are other comments.

> 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.

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",
>       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.

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