"must"
On Sun, Nov 16, 2008 at 6:42 PM, David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
Peter Michaux wrote:
On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <petermichaux at gmail.com> wrote:
Also is it "should" or "must"? RFC documents are usually very strict about defining "should" etc and I don't see a definition of "should" before page 41 of the pdf where this use occurs.
I think explicitly adopting these definitions would be a good step in improving the clarity of the ECMAScript standard.
I advise caution here: many, perhaps most of the existing uses of "must" or "must not" in ECMA-262 or the Kona draft are not consistent with the RFC2119 definitions.
Regardless of the source of key word definitions like "must" and "should", do you agree that precises definitions and consistent usage would be beneficial to the clarity of the document and a worthwhile improvement? It may require some rewording but at least these words are easy to find.
Peter
On Nov 16, 2008, at 6:42 PM, David-Sarah Hopwood wrote:
Peter Michaux wrote:
On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <petermichaux at gmail.com
wrote:
Also is it "should" or "must"? RFC documents are usually very strict about defining "should" etc and I don't see a definition of "should" before page 41 of the pdf where this use occurs.
I think explicitly adopting these definitions would be a good step in improving the clarity of the ECMAScript standard.
I advise caution here: many, perhaps most of the existing uses of
"must" or "must not" in ECMA-262 or the Kona draft are not consistent with
the RFC2119 definitions.The RFC2119 meaning of MUST is a mandatory conformance requirement on implementations of the protocol or format defined in the RFC. For a programming language spec, it is ambiguous whether this means a requirement on valid programs, or a requirement on the language implementation. It's important for those to be distinguished.
RFC2119 is a mandatory conformance requirement on a particular
conformance class. For many specs the set of conformance classes may
be clear from context; when this is not so, it's good to explicitly
define conformance classes such as "conforming implementation" and
"conforming program" and make clear which conformance requirements
apply to which.
(Note, depending on how the conformance requirements are defined,
conforming implementations may be required to have particular behavior
for some nonconforming programs.)
If a mathematical operation or function is applied to a floating- point number, it should be understood as being applied to the exact mathematical value represented by that floating-point number; such a floating-point number must be finite, and if it is +0 or 0 then the corresponding mathematical value is simply 0.
This use of "must" is an assertion that the specification never calls for a mathematical operation or function to be applied to an infinite or NaN value (so if it did, that would be a specification
bug); not that an implementation is required not to do so.
It would be better not to use "must" in cases like this. This is a
statement of fact about the specification, not a conformance
requirement on any conformance class. Even if there is no formal
citation of RFC2119, nontheless such informal use of "must" may
confuse experienced readers of various specifications.
, Maciej
Peter Michaux wrote:
On Sun, Nov 16, 2008 at 6:42 PM, David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk> wrote:
Peter Michaux wrote:
On Sat, Nov 15, 2008 at 11:18 PM, Peter Michaux <petermichaux at gmail.com> wrote:
Also is it "should" or "must"? RFC documents are usually very strict about defining "should" etc and I don't see a definition of "should" before page 41 of the pdf where this use occurs. www.ietf.org/rfc/rfc2119.txt
I think explicitly adopting these definitions would be a good step in improving the clarity of the ECMAScript standard.
I advise caution here: many, perhaps most of the existing uses of "must" or "must not" in ECMA-262 or the Kona draft are not consistent with the RFC2119 definitions.
Regardless of the source of key word definitions like "must" and "should", do you agree that precises definitions and consistent usage would be beneficial to the clarity of the document and a worthwhile improvement?
Absolutely. As Allen Wirfs-Brock says, we need to find out what the ECMA constraints/conventions are first.
Ecma would prefer that we follow the ISO Directives, Part 2. In there you will find that "shall" and "may" are the words to use
John **************Get the Moviefone Toolbar. Showtimes, theaters, movie news & more!(pr.atwola.com/promoclk/100000075x1212774565x1200812037/aol?redir=htt p://toolbar.aol.com/moviefone/download.html?ncid=emlcntusdown00000001)
Peter Michaux wrote:
I advise caution here: many, perhaps most of the existing uses of "must" or "must not" in ECMA-262 or the Kona draft are not consistent with the RFC2119 definitions.
The RFC2119 meaning of MUST is a mandatory conformance requirement on implementations of the protocol or format defined in the RFC. For a programming language spec, it is ambiguous whether this means a requirement on valid programs, or a requirement on the language implementation. It's important for those to be distinguished.
ECMA-262 and Kona use "must" sometimes as a requirement on the language implementation, but at least as often to mean a property that is necessarily logically true (or false for "must not"), assuming that the spec is self-consistent -- that is, a tautology or an implication of other requirements, not an independent conformance requirement.
For example:
If a mathematical operation or function is applied to a floating-point number, it should be understood as being applied to the exact mathematical value represented by that floating-point number; such a floating-point number must be finite, and if it is +0 or 0 then the corresponding mathematical value is simply 0.
This use of "must" is an assertion that the specification never calls for a mathematical operation or function to be applied to an infinite or NaN value (so if it did, that would be a specification bug); not that an implementation is required not to do so.