On Tue, Sep 6, 2011 at 2:01 AM, Brendan Eich <[email protected]> wrote:
> On Sep 5, 2011, at 9:36 PM, John J Barton wrote: > > On Sun, Sep 4, 2011 at 1:42 PM, Brendan Eich <[email protected]> wrote: > >> On Sep 4, 2011, at 11:06 AM, John J Barton wrote: >> >> As a reader I have to parse the function carefully to look for the >> 'yield'. If I find one, then I know that this is not actually a function >> after all. Then I need to mentally draw a line after the yield and label it >> "entry-point #2". >> >> >> This is addressed in ES6 by changing the head of the generator function as >> follows: >> >> spawn(function* () { >> try { >> var [foo, bar] = yield join(read("foo.json"), >> read("bar.json")).timeout(1000); >> render(foo); >> render(bar); >> } catch (e) { >> console.log("read failed: " + e); >> } >> }); >> >> (For others who have some trouble seeing the difference, here the > function keyword is followed by the multiplication symbol). > > "generator() {}" would make a lot more since to me, it would more clearly > alert the reader at no added cost for the writer, as well as helping new > users of this feature separate it's effect from functions. > > > We considered that, but generator is not reserved, and reserving it in ES6 > requires newline sensitivity at least. Consider an anonymous generator > similar to the one you typed: > > generator() > {...} > > where ... is actual code (and the {...} style may use multiple lines and > indentation). This could be valid code in the field today, relyling on ASI > to insert the semicolon after "generator()". > > What's more, the precedent in Python is not a negative or a trivial > benefit. Besides reusing brain-print, we stand on field-tested design in a > similar language. Python uses def for both functions and generators. > But isn't this just a design flaw in python (and js 1.7) -- remedied, no less, by your disambiguating asterisk? Personally I'm fond of the asterisk, and the symmetry of function* and yield*, but this is a distinct grammatical construct from function, right? This argument doesn't strike me as very winful against any other (syntactically safe) spelling. > Next I have to read through the source of spawn() and track the lifetime-of >> and references-to the object it received, seeking calls to send(). >> >> >> No, you can use spawn as a black box. It's an API entry point to the >> taskjs library. You do not need to read the source to use an API. >> > > Hmm., the doc http://dherman.github.com/taskjs/doc/api.html says: > Task spawn(generator function thunk) > But as I understand it, the send() plays a role in the API to spawn > correct? > > > The value sent to yield expressions in your generator, yes. So? Again that > does not mean you must read the inside of the black box. The API docs may be > lacking, of course :-|. > What it's really lacking is a version with * syntax of harmony generators, which fixes the locality of reference problems and makes it more clear when you're working with a task. Any word on when they're intended to land in spidermonkey? I see Dave Herman filed a bug back in June but there's no status on it. [snipped the rest]
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
