[js-api] Possible alignment of abstract closure conventions with ECMA-262

[ShinWonho]

In the JS-API specification, there are a few cases where abstract closures are used.
I was wondering if these could follow the same conventions as in ECMA-262 for consistency.

React step in js-api specification

For example, in the algorithm “Instantiate a promise of a module”, there is a step called react.
This step takes as input some substeps to perform when the promise is fulfilled or rejected.
Each of these substeps is later passed to ECMA-262’s CreateBuiltinFunction, which expects an abstract closure as an argument.
In other words, the react step treats those substeps as abstract closures in the ECMA-262 sense.

However, the way these closures are represented in the JS-API specification looks quite different from the convention used in ECMA-262.

Abstract closure in ECMA-262

Abstract closure in WebIDL

In ECMA-262, abstract closures are explicitly marked as such, with their parameters and captured variables listed.
While the JS-API specification depends on the Infra Standard (which may justify stylistic differences), another Infra-based specification, WebIDL, also follows the ECMA-262 convention.

Would it make sense for the JS-API specification to adopt a similar notation, explicitly marking these substeps as abstract closures like below?
This could make it clearer that they correspond to ECMA-262 abstract closures and help maintain consistency across related specifications.
For example, it might be written as follows instead:

[Ms2ger]

Thanks for the comment. "react" does not deal with abstract closures (explicitly); WebIDL seems to only use abstract closures in two cases, and only when used as an argument to ES CreateIteratorFromClosure (which is defined as taking them).

If WebIDL was changed to expect abstract closures here, I would support the change you suggest. As it is, it does not seem to be a clear improvement.

In any case, making a change like this would sadly be very low on my list of priorities; reviewing one is probably more likely to happen.

[ShinWonho]

In fact, I am very interested in revising and improving specifications.
As a graduate student at KAIST, my interest goes beyond fixing a few parts of a specification.
I am interested in refining the specification as a whole and exploring the various possibilities that can be achieved through it.
In this regard, my advisor and I would greatly appreciate the opportunity to have a video chat with you.