Single frame continuations using yield keyword with generators compatibility proposal

David Herman dherman at
Tue Apr 6 14:41:35 PDT 2010

> The key idea of this approach is that when a function is called that
> contains a yield operator, rather than following a hard-coded
> prescription to return an generator/iterator object, this triggers a
> call to the startCoroutine variable (from the current lexical scope)

Totally opposed. I don't even think this is a fruitful avenue to go down. Going through backflips to tie together a couple different features is really beyond the goals of Harmony (small, orthogonal).

And this approach is particularly bad. What you're talking about creates a context-dependency, which is a nasty refactoring hazard and violates local reasoning about code. Macrologists sometimes describe what you're talking about as a violation of "referential transparency": well-behaved syntactic forms shouldn't change their meaning when you move them from one context to another. Specifically, if the definition of a syntactic form refers to a variable, that reference should be fixed no matter where you use the syntactic form. For exactly these reasons.

I see *why* you're trying to do this: you essentially are trying to introduce a kind of static operator overloading in order to generalize the meaning of `yield'. But this isn't solving a real need, and overloading of any sort isn't currently a priority.


More information about the es-discuss mailing list