Editorial: Recast NormalCompletion + ThrowCompletion

[jmdyck]

... as regular abstract operations.

See

• Editorial: create a ThrowCompletion abstract operation to reduce boilerplate #1142 (comment) and following
• Editorial: more obvious syntax for macros #2384 (comment) and following

[bakkot]

Suggested change

	<p>The abstract operation NormalCompletion takes argument _value_ (an ECMAScript language value or ~empty~). It performs the following steps when called:</p>
	<p>The abstract operation NormalCompletion takes argument _value_. It performs the following steps when called:</p>

Given that the type isn't accurate, best to leave it out for now, I think (even though the inaccuracy exists elsewhere).

[jmdyck]

Urgh, okay, done.

[michaelficarra]

How is it inaccurate?

[bakkot]

Normal completions hold values which are not ES language values or ~empty~. The table you've screenshotted is wrong; that's the "elsewhere" I was referring to.

(For example, PropertyBindingInitialization returns a completion record holding a list. jmdyck has a larger list of examples here.)

[jmdyck]

For explicit calls to NormalCompletion, I suspect an ECMAScript language value or ~empty~ actually is accurate. However, there are also implicit calls to NormalCompletion, and those get us into issue #496. I.e. the spec is inconsistent, and one possible resolution of that inconsistency is that the [[Value]] field of a completion record can be many more things than just an ECMAScript language value or ~empty~.

[jmdyck]

force-pushed to:

• rebase to master,
• resolve merge conflicts from PR 545 (use structured headers), and
• squash commits into one.