2013/9/1 Brendan Eich <[email protected]>: > Generators are a kind of factory function. When you call a generator, you > get an iterator with a bit of extra protocol (.throw as well as .next). > > No big deal, lots of API contracts are implemented by functions, you say -- > why does this one deserve special head syntax. 'return' can be hard to spot, > just as 'yield' could be hidden, in a large body -- and return of a > certain-shaped object as part of an API contract could be even harder to > discern.
Well, you don't answer the question, why do you think *your* APIs are truly better then others? In other words, why do you think there is a kind of difference between a normal function and the factory function, and think that the latter is *evil*? I don't see the reason why you think the latter can be harder to find. > In general, you have a point. Languages such as Scheme or Racket enable > their users customize built-in syntax all the time to express contracts > better, even with static syntactic checking using macros. Even macro-less > languages may have decorators (CoffeeScript's syntax cleverly enables > decorators "for free"). I'm not talking about languages with macros. Almost all macro-less languages could decide to have syntactic decorators when newly introducing generators to themselves, but in fact they did not. > You might think of function* as decorator syntax. It's important, given the > 'yield' backward compatibility issue, not to make the syntax too > heavyweight. One character is as minimal as we can get. > > But now I'm just shoring up the argument based on compatibility. You'll have > to get Mark or someone else to help you understand their particular argument > that the function head needs decoration to alert the reader to the possible > (not required) presence of yield in the body. Sure, I want :) > Note also the empty-body basis case -- that's a good argument for function* > independent from the backward-compatibility and good-for-readers arguments. > > /be > >> Yuichi Nishiwaki <mailto:[email protected]> >> August 31, 2013 2:12 PM >> >> I get the point. Indeed. Modes are a kind of magic... >> >> Regarding the secondary reason: >> I don't understand the "difference" well, could you explain in detail? >> You know, all other languages that are dynamically typed and have >> generators, such as python, lua, and even JavaScript 1.8 don't >> distinguish two kinds of the functions. >> I guess this directly means that there isn't something different as >> you said (because they all have more or less made successful). >> And in my personal view, yield is something that can be generalized >> together with return, like >> >> - return: discards the succeeding partial continuation there >> - yield: preserve the succeeding partial continuation there >> >> It is very clear in a sense, I believe. So my guess is that the >> strangeness yields have is a mater of getting used to, and that it is >> much more natural to treat two of them as a same thing. >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> Mark S. Miller <mailto:[email protected]> >> August 31, 2013 1:33 PM >> >> On Sat, Aug 31, 2013 at 1:14 PM, Yuichi Nishiwaki >> <[email protected] <mailto:[email protected]>> wrote: >> >> OK, right. I understand my first propose does not work. :-| >> So one more question is how about making '*' optional in strict mode? >> (Should I separate the topic to another?) >> >> 2013/9/1 Brendan Eich <[email protected] >> <mailto:[email protected]>>: >> >> > Let's not go in circles -- the primary reason for function* is >> because yield >> > is not reserved in JS and is used by web content as a plain >> identifier. It >> > is a low-precedence unary prefix operator, so cannot be contextually >> > reserved by a grammatical restriction as "module" can. It needs >> opt-in >> > syntax. >> > >> > Separately, some on TC39 want a flag on the function, in the >> head syntax, to >> > alert readers to the generator. That's a secondary reason, >> independent and >> > not as strong in my view. >> >> >> I am one of those on TC39 that want the visible flag. Since, in my view, >> the only non-mistaken need to preserve sloppy mode is as an ES3 >> compatibility mode and ES3 has no generators, I consider this flagging issue >> to be the important one. Yes, you have to read the function to know *what* >> it generates. But even before you've figured that out, your whole effort to >> read the function is different once you know you're reading a generator >> function. Better to know it early. >> >> Code is read much more than it is written -- at least code that matters. >> >> >> > >> > There's nothing to "get" or "not get" about backward >> compatbility. It just >> > "is". :-| >> > >> > /be >> > >> >> Yuichi Nishiwaki <mailto:[email protected] >> <mailto:[email protected]>> >> >> August 31, 2013 12:55 PM >> >> >> >> I can't get the point, why you need to know if the function is a >> >> generator or not at a glance? >> >> >> >> 1. Forcing users to mark the function as a generator is only a >> >> duplication. It basically doesn't have any meaning other than >> >> double-checking, and fundamental risk for the unintentional >> creation >> >> is still not removed. >> >> 2. Even if you know the function is a generator in early, you still >> >> need to read the entire source code to get the information >> about what >> >> the generator yields and when it stops. >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] <mailto:[email protected]> >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> Oliver Hunt <mailto:[email protected] <mailto:[email protected]>> >> >> >> August 31, 2013 12:25 PM >> >> >> >> On Aug 31, 2013, at 12:15 PM, Yuichi >> Nishiwaki<[email protected] >> <mailto:[email protected]>> >> >> >> wrote: >> >> >> >>> Hi all, I just found a post that the current generator syntax >> >>> (function *) seems have decided in: >> >>> >> >>> >> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html >> >>> >> >>> According to the post, the biggest reason the star syntax is >> adopted >> >>> for now is that you cannot write empty generators with star-less >> >>> functions in a consistent simple way. But the situation has >> changed, >> >>> and in the current spec (rev 17) yield* is now capable of >> taking any >> >>> kind of iterator, so you can make empty generators just like >> >>> >> >>> ```js >> >>> function * () { >> >>> yield * []; >> >>> } >> >>> ``` >> >>> >> >>> This looks enough good and simple at least to me. And I wonder >> if even >> >>> now generators still need to be declared with 'star's. What >> are the >> >>> advantages of 'star'ed generators rather than 'star'-lesses? >> If not >> >>> exist, shouldn't it be removed (for the simplicity)? >> >>> >> >> >> >> The reason for the * is substantially (IIRC) to make it >> possible for an >> >> engine >> >> to help prevent developers from unintentionally creating a >> generator >> >> function, >> >> and to make it possible for someone attempting to use a function to >> >> identify immediately >> >> whether it is a generator or a regular function. >> >> >> >> --Oliver >> >> >> >>> Thank you. >> >>> >> >>> -- >> >>> Yuichi Nishiwaki >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] <mailto:[email protected]> >> >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] <mailto:[email protected]> >> >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> Yuichi Nishiwaki <mailto:[email protected] >> <mailto:[email protected]>> >> >> August 31, 2013 12:15 PM >> >> >> >> Hi all, I just found a post that the current generator syntax >> >> (function *) seems have decided in: >> >> >> >> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html >> >> >> >> According to the post, the biggest reason the star syntax is >> adopted >> >> for now is that you cannot write empty generators with star-less >> >> functions in a consistent simple way. But the situation has >> changed, >> >> and in the current spec (rev 17) yield* is now capable of >> taking any >> >> kind of iterator, so you can make empty generators just like >> >> >> >> ```js >> >> function * () { >> >> yield * []; >> >> } >> >> ``` >> >> >> >> This looks enough good and simple at least to me. And I wonder >> if even >> >> now generators still need to be declared with 'star's. What are the >> >> advantages of 'star'ed generators rather than 'star'-lesses? If not >> >> exist, shouldn't it be removed (for the simplicity)? >> >> >> >> Thank you. >> >> >> >> -- >> >> Yuichi Nishiwaki >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] <mailto:[email protected]> >> >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> > >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> -- >> Cheers, >> --MarkM >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> Yuichi Nishiwaki <mailto:[email protected]> >> August 31, 2013 1:14 PM >> >> OK, right. I understand my first propose does not work. :-| >> So one more question is how about making '*' optional in strict mode? >> (Should I separate the topic to another?) >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> Brendan Eich <mailto:[email protected]> >> August 31, 2013 12:58 PM >> Let's not go in circles -- the primary reason for function* is because >> yield is not reserved in JS and is used by web content as a plain >> identifier. It is a low-precedence unary prefix operator, so cannot be >> contextually reserved by a grammatical restriction as "module" can. It needs >> opt-in syntax. >> >> Separately, some on TC39 want a flag on the function, in the head syntax, >> to alert readers to the generator. That's a secondary reason, independent >> and not as strong in my view. >> >> There's nothing to "get" or "not get" about backward compatbility. It just >> "is". :-| >> >> /be >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> Yuichi Nishiwaki <mailto:[email protected]> >> August 31, 2013 12:55 PM >> I can't get the point, why you need to know if the function is a >> generator or not at a glance? >> >> 1. Forcing users to mark the function as a generator is only a >> duplication. It basically doesn't have any meaning other than >> double-checking, and fundamental risk for the unintentional creation >> is still not removed. >> 2. Even if you know the function is a generator in early, you still >> need to read the entire source code to get the information about what >> the generator yields and when it stops. >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
