various editorial changes for comparisons

[michaelficarra]

Extracted from #2821. Fixes #2794.

Editorial choices included in this PR

• use =, ≠, <, ≤, >, and ≥ for mathematical value and bigint comparisons (except in asserts); prefer = over ≠
• use is, is not, <, ≤, >, and ≥ for number comparisons
• use SameValue(..., ...) is *true* for equality comparison of symbols (except well-known) / objects / unknown ECMAScript language values
• use is and is not for equality comparison of all other values, including booleans, strings, well-known symbols, null, undefined, enums, etc; avoid "is different from" or "is the same as"
• prefer "if a is either b or c" over "if a is b or a is c"; use "any of" in place of "either" when more than 2 options
• prefer "if a is c and b is c" over "if a and b are both c"
• presence in a List is tested with _list_ contains _element_ or _list_ does not contain _element_, not _element_ is an element of _list_ or _element_ is in _list_
• don't say the value of _a_; just use _a_
• prefer "if a or b" over "if a or if b"; prefer "if a and b" over "if a and if b"
• prefer "whose _ is _" over "whose _ is that of _"

Other editorial choices (still to do, not as part of this PR)

• use a/an/a new for creating and referencing values with identity
• use the for referencing values without identity

[michaelficarra]

FYI I'm done with my review of the spec for this PR. All changes should now be included and rebased on main. Next, I'll go through all the changes and pull out anything not identity/comparison related into separate PRs, then I'll mark this PR as ready for review.

[michaelficarra]

Note to reviewers: I'm just swapping the positive/negative branches here.

[michaelficarra]

Okay that was actually easier than I expected. This is ready for review.

[michaelficarra]

resolved conflicts

[bakkot]

@syg may not care to review again, since we've talked about all the decisions, but we should check before landing.

[jmdyck]

Re-doing my analysis from Oct 17...

---

Composing a condition from sub-conditions...

... when there are only 2 sub-conditions:

  229  {COND} and {COND}
   80  {COND} or {COND}
    4  {COND} unless {COND}
vs
    2  {COND}, or if {COND}
    1  {COND}, or {COND}
    1  {COND}, unless {COND}
vs
    1  either {COND} or {COND}

... when there are 3+ sub-conditions:

    1  {COND}, {COND}, or {COND}
    8  {COND}, {COND}, and {COND}
    6  {COND}, {COND}, {COND}, and {COND}
vs
    5  {COND} and {COND} and {COND}
    1  {COND} or {COND} or {COND}
    1  {COND} or {COND} or {COND} or {COND}

(And while I'm here, conditions that mix operators without parens:

    1  {COND} and {COND} or {COND} and {COND}
    3  {COND} and {COND}, or if {COND} and {COND}
    2  {COND} and {COND}, or {COND} and {COND}
    2  {COND} or {COND} <ins>and {COND}</ins>
    1  {COND} unless {COND} and {COND}
    2  {COND}, or if {COND} and {COND}

)

---

Testing whether or not a value matches some list of descriptions (e.g., _x_ is *undefined* or a String)...

... when there are only 2 descriptions:

  189  {D} or {D}
vs
  376  either {D} or {D}
vs
   26  either {D}, or {D}

... when there are 3+ descriptions:

    8  any of {D}, {D}, or {D}
    6  any of {D}, {D}, {D}, or {D}
    4  any of {D}, {D}, {D}, {D}, or {D}
    1  any of {D}, {D}, {D}, {D}, {D}, or {D}
    1  any of {D}, {D}, {D}, {D}, {D}, {D}, or {D}
    1  any of {D}, {D}, {D}, {D}, {D}, {D}, {D}, or {D}
vs
    6  either {D}, {D}, or {D}
    5  either {D}, {D}, {D}, or {D}
vs
    3  one of {D}, {D}, or {D}
    1  one of {D}, {D}, {D}, or {D}
vs
   33  {D}, {D}, or {D}
    7  {D}, {D}, {D}, or {D}
    2  {D}, {D}, {D}, {D}, or {D}
    2  {D}, {D}, {D}, {D}, {D}, or {D}
    1  {D}, {D}, {D}, {D}, {D}, {D}, {D}, {D}, {D}, {D}, {D}, or {D}

[jmdyck]

Some things I didn't put into PR #2970.

[jmdyck]

I agree that is one of |LineTerminator| should be changed, but this use of "is matched by" is odd. Normally, "X is matched by |Foo|" means that:

• X is a chunk of source text, and
• X (or, more likely, some larger source text that contains X) has been parsed according to a grammar, resulting in a |Foo| Parse Node that corresponds to X.

But neither of those points is true here.

Maybe:

Suggested change

	1. If _e_ = 0, or if _rer_.[[Multiline]] is *true* and the character _Input_[_e_ - 1] is matched by |LineTerminator|, then
	1. If _e_ = 0, or if _rer_.[[Multiline]] is *true* and the character _Input_[_e_ - 1] is one of U+000A (LINE FEED), U+000D (CARRIAGE RETURN), U+2028 (LINE SEPARATOR), or U+2029 (PARAGRAPH SEPARATOR), then

[jmdyck]

(ditto previous comment)

[jmdyck]

There are several remaining occurrences of "X and Y are both Z", so it's unclear why this particular one would be changed.

[bakkot]

I don't love the ToIntegerOrInfinity -> ToUint32 change, because ToUint32 has wrapping behavior. It happens that the wrapping behavior doesn't come up in this case because array indices are bounded below the modulus, but I don't like making the reader think that hard.

Can I suggest ! ToNumber(_P_) ≥ _newLen_ instead? I would also be fine with StringToNumber(_P_) ≥ _newLen_, or with ! ToIntegerOrInfinity(_P_) ≥ ℝ(_newLen_).

[jmdyck]

I don't love the ToIntegerOrInfinity -> ToUint32 change, because ToUint32 has wrapping behavior. It happens that the wrapping behavior doesn't come up in this case because array indices are bounded below the modulus, but I don't like making the reader think that hard.

Note that there's a call to ToUint32(_P_) just 3 lines down, so they're going to have to think that hard anyway. (On the other hand, maybe that call should change too. Not in this PR necessarily.)

Can I suggest ! ToNumber(_P_) ≥ _newLen_ instead? I would also be fine with StringToNumber(_P_) ≥ _newLen_, or with ! ToIntegerOrInfinity(_P_) ≥ ℝ(_newLen_).

Those all work. The algorithm doesn't currently use ℝ (or any mathematical values at all?), so I think it's easier on the reader if we don't use the third alternative. Between the other two, I have a mild preference for StringToNumber(_P_). (The name is more explicit, it's a simpler AO, and avoiding ! in a condition is a bonus.)