Editorial: Add Yield, CreateIteratorFromClosure, CreateAsyncIteratorFromClosure abs op.

[Jack-Works]

Introduce Yield and CreateIteratorFromClosure, CreateAsyncIteratorFromClosure in the spec to make it easier to define builtin generators.

Diff: https://arai-a.github.io/ecma262-compare/?pr=2045

[ljharb]

How is this normative? It seems purely editorial.

[ljharb]

Is this meant to be useful for existing iterator-producing methods and the iterator helpers proposal?

[Jack-Works]

I did a quick check, the current @@iterator on Array isn't a GeneratorFunction.
If we use it to replace the current iterator producing methods, it might be a breaking change (change @@iterator from a normal function to a GeneratorFunction)

Yes, it's for the iterator helpers (and my range proposal)

[ljharb]

The plan for iterator helpers is to not have an actual generator function exposed to users, and i assume the same would be true for range. The intention is for each thing to be a normal function (just like all the existing iterator producers) that internally calls an abstract operation that’s implemented with generator spec mechanics.

[Jack-Works]

@ljharb rewrited

[ljharb]

I'll be most interested to see this technique used to non-observably improve the way, for example, String.prototype.matchAll is specified.

[Jack-Works]

I'll be most interested to see this technique used to non-observably improve the way, for example, String.prototype.matchAll is specified.

Can the current PR do that?

[ljharb]

I feel pretty strongly that the current PR must do that, since we don't generally add abstract operations that have zero uses :-)

[Jack-Works]

I feel pretty strongly that the current PR must do that, since we don't generally add abstract operations that have zero uses :-)

I'll try to convert some existing algorithms later to verify my idea

[Jack-Works]

I found it is not easy to move to CreateBuiltinGeneratorFunction cause they have their own prototype, the next method that does the brand checking.

[Jack-Works]

I have rewritten the String@@iterator with this new abstract op @ljharb

[ljharb]

This is very interesting, I think I'm going to like it a lot.

It'd be great to convert a few more builtins to get a feel for how that would work - perhaps matchAll, Array, and Map or Set?

[Jack-Works]

how's that going? 🙈 @ljharb

[ljharb]

@Jack-Works it needs further editor call discussion; hopefully we can update this week.

[ljharb]

@Jack-Works hi! we discussed this, and we'd love to see more examples of iterator-producers converted to use this spec text. In particular, https://tc39.es/ecma262/#sec-string.prototype.matchall, https://tc39.es/ecma262/#sec-array.prototype.keys, and https://tc39.es/ecma262/#sec-map.prototype.keys.

[devsnek]

This isn't the design we're planning to use for iterator helpers, so I'm not sure how useful it would be to merge it in its current form.

[Jack-Works]

This isn't the design we're planning to use for iterator helpers, so I'm not sure how useful it would be to merge it in its current form.

The design in this PR is learned from the iterator helper's current spec. I try to formalize words like

X is a built-in generator function which, when called, performs the following prelude steps:

Set lastValue to Yield(mapped).

and I need to support the current built-in generator-like methods behavior too.

My design work in the following way:

• A built-in generator can have prelude steps (to do the parameter check) before they're getting iterated.
• A built-in generator can declare its returning iterator to have a [[IteratorKind]] slot. This is used for the brand check, therefore the %StringIterator%.next.call(_array_iterator_) can be banned (to keep the current behavior).

If there is any design not compatible with the iterator helper, please point out and I'll try to fix that, thanks! @devsnek

[Jack-Works]

@Jack-Works hi! we discussed this, and we'd love to see more examples of iterator-producers converted to use this spec text. In particular, https://tc39.es/ecma262/#sec-string.prototype.matchall, https://tc39.es/ecma262/#sec-array.prototype.keys, and https://tc39.es/ecma262/#sec-map.prototype.keys.

done! 👀

[devsnek]

@Jack-Works we're not using prelude and body steps anymore. Here's an example of what we have atm, though its not final:

[Jack-Works]

Is there specific reason to use the new form you screenshotted instead of the old form?

[devsnek]

@Jack-Works we had pushback against exposing the functions directly and pushback against the "prelude"/"body" pattern.

[Jack-Works]

@Jack-Works we had pushback against exposing the functions directly and pushback against the "prelude"/"body" pattern.

LGTM, I'll adjust the design to match the style you posted later.

[Jack-Works]

[2020-06-30T08:45:52.451Z] Linting...

Error: expecting ordered list, got whitespace

    at Parser.parseAlgorithm (/home/travis/build/tc39/ecma262/node_modules/ecmarkdown/dist/parser.js:41:19)

Why the linter didn't tell me it failed at which line instead of this confusing message... 🤦‍♂️

Oh okay I have a syntax error here.

[bakkot]

Looks pretty good! There's a couple of small correctness things and a couple of small editorial issues which should get fixed before landing, and it also needs a rebase.

[Jack-Works]

has updated to the mainstream by merge. do I still need a rebase?

[bakkot]

has updated to the mainstream by merge. do I still need a rebase?

No, that's fine.

[bakkot]

Needs a couple of last formatting tweaks. Otherwise LGTM.

[ljharb]

@Jack-Works this PR will need a rebase, as well - it has a merge conflict.

resolved

[Jack-Works]

Cool