> 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. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
