Definition of 'prelude steps' for generator function algorithms

[avandolder]

Currently, the algorithms for the proposed helpers that use generator functions are split into prelude steps and body steps. It is my understanding that this is to allow for the checks in the prelude to be done eagerly when the helper is first called, regardless of when the generator is consumed. However, this distinction between prelude and body steps is not defined in the Algorithms Conventions section of ECMA 262.
As a result, should such a definition be added into this proposal?

[jorendorff]

Per some discussion with @devsnek, I think the current idea is for the helper methods themselves to be plain builtin functions which return generator objects. That solves the problem with how to make the prelude steps happen early.

We'll see what TC39 has to say about this at the upcoming meeting.

[devsnek]

Sorry for not noticing this issue. What I'm working with at the moment looks like this:

I'm hoping it is the final iteration but I'm not sure, as Jason says we will be discussing it during the upcoming plenary.

[ljharb]

@jorendorff return generator objects or just regular iterators?

[devsnek]

cc @michaelficarra @decompil3d

[jorendorff]

@ljharb Generator objects. I'll be presenting this for discussion at the plenary.

[rwaldron]

While writing tests for this proposal I noticed that the descriptions may say, for example:

%AsyncIterator.prototype%.asIndexedPairs is a built-in async generator function

Shouldn't these then say "%AsyncIterator.prototype%.asIndexedPairs is a built-in function"?

[devsnek]

@rwaldron the current spec text is very old, check out #112

[rwaldron]

@devsnek Got it. When can we expect that changeset to land?

[devsnek]

@rwaldron after tc39/ecma262#2045 i think

[Jack-Works]

#2045 has landed 🥳

[rwaldron]

@jugglinmike this is relevant to your interests!