David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sun Nov 16 18:42:11 PST 2008

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.
> http://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.

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.

David-Sarah Hopwood

More information about the Es-discuss mailing list