Editorial: Unify 'else' and 'otherwise'

[jungwngkim]

This PR implements points discussed in issue #3648

Although I've tried to replace every occurrence of 'otherwise' with 'else' in the algorithm steps, there were 16 cases where simply replacing with 'else' lead to awkward sentence. I listed them below.

$ grep "1\. .* otherwise" spec.html -n
(...) the host is a web browser or otherwise supports <emu-xref> # 11 cases
(...) if _Desc_ has that field, or to the attribute's <emu-xref>default value</emu-xref> otherwise. # 4 cases
NOTE: (...) unless specified otherwise. # 1 case

[michaelficarra]

@tc39/ecma262-editors For the single-line if/else where both branches return, do we want to just split them up into two steps?

[syg]

After discussion with editor group, as an editorial convention, let's do:

• If a conditional has just two branches (i.e. not an if-else cascade like in some Math functions), and the two branches are symmetric and short, prefer a one-liner.
• If a conditional has more than two branches (i.e. is an if-else cascade), prefer multi-lines with early return without a preceding Else, on branches after the first one.
• If a conditional has just two branches but the complexity of the two branches are asymmetric (e.g. one branch has more steps than the other), prefer multi-line with early return without a preceding Else, on the else branch.

[syg]

Good to land as is, can fixup afterwards.

[jungwngkim]

Thank you all for the discussion.

I've implemented the fixes for rules 2 and 3, which were mainly about short-circuiting (early returns) in If-steps and removing the 'Else'.

There were 74 candidates (based on the grep below), 62 of which were fixable. These fixes cover the above suggestions.

// short circuit candidates (before: 74, now: 12)
pcregrep -nM "(([rR]eturn)|([tT]hrow)) .*\.\n *1\. Else," ./spec.html

Currently, the first rule 'one-liner when symmetric and short' isn't implemented, which I plan to implement shortly after this.

[michaelficarra]

This is going to need a rebase.

[michaelficarra]

Let's invert this condition.

[jungwngkim]

Sure, I'll reflect the feedback on the following commit.

[michaelficarra]

LGTM otherwise! I'm looking forward to your follow-up PR.

[michaelficarra]

@jhnaldo Shouldn't the inline warnings only show up when the algorithm was previously understood by esmeta and becomes not understood due to new phrasing? What's going on here? Are these changes actually causing loss of precision?

[jhnaldo]

@michaelficarra You're absolutely right. I realize now that the current logic is too naive. It triggers warnings for any change in a line, even if the phrasing was already unsupported. This is likely causing the confusion you mentioned. I'll fix this to compare the base/head results so that only truly 'new' yet-phrases are reported. I'll update this as soon as possible.

[michaelficarra]

@jhnaldo There's no rush! Enjoy the holiday.

[jungwngkim]

I've implemented rule 1 (inline if-else) for simple returns of boolean and number.

For each case, multilines are merged into single-line if-else.

Also, minor short-circuit fixes for if/else-if were made.

# simple true/false returns
pcregrep -cM "return \*(false|true)\*\.\n *1. Return \*(false|true)\*" ./spec.html # (78 -> 38)
pcregrep -cM "return \*(true|false)\*; else return \*(true|false)\*" ./spec.html   # (30 -> 71)

# simple integer returns
pcregrep -cM "return (\d+)\.\n *1. Return (\d+)" ./spec.html # (3 -> 1)
pcregrep -cM "return (\d+); else return (\d+)" ./spec.html   # (2 -> 4)

# simple Number value returns
pcregrep -cM "return \*[+-]?\d+\*<sub>𝔽</sub>\.\n *1\. Return \*[+-]?\d+\*<sub>𝔽</sub>" ./spec.html # (5 -> 3)
pcregrep -cM "return \*[+-]?\d+\*<sub>𝔽</sub>; else return \*[+-]?\d+\*<sub>𝔽</sub>" ./spec.html    # (7 -> 9)

# inverted inline if-else
grep -c "1\. If .* not .*, .*; else .*\." ./spec.html   # (10 -> 3)

[jungwngkim]

I attempted to work on cases other than simple returns, but it was difficult to proceed because the criteria for symmetric/asymmetric and short/long were unclear.

For now, I have merged or split rather simple/straightforward if-else blocks based on a 180-character threshold. The remaining cases seem to require further discussion.

I am attaching grep commands and histograms for reference.

# inline if-else (single-line)
grep -o "1\. If .*, .*; else .*\." ./spec.html

# inline if + inline else (double-line)
pcregrep -M "1\. If .*, .*\n *1\. Else, .*" ./spec.html

# if + single body step + else + single (not always) body step (multi-line)
pcregrep -M "1\. If .*, then\n *1\. .*\n *1\. Else,\n *1\. .*" ./spec.html

inline if-else histogram

grep -o "1\. If .*, .*; else .*\." ./spec.html | \
awk '{print int(length/30)*30}' | \
sort -n | \
uniq -c | \
awk '{printf "[%3d-%3d] (%3d) : ", $2, $2+29, $1; for(i=0;i<$1;i++) printf "#"; print ""}'

# Before
[ 30- 59] ( 14) : ##############
[ 60- 89] ( 66) : ##################################################################
[ 90-119] ( 94) : ##############################################################################################
[120-149] ( 18) : ##################
[150-179] (  7) : #######
[240-269] (  1) : #
[270-299] (  1) : #
[360-389] (  1) : #

# After (>180 split into multiline, <180 merged from double and multiline)
[ 30- 59] ( 14) : ##############
[ 60- 89] ( 78) : ##############################################################################
[ 90-119] (109) : #############################################################################################################
[120-149] ( 18) : ##################
[150-179] (  7) : #######