> Brian Kardell <mailto:bkardell at gmail.com>
> August 31, 2013 4:21 PM
>
>
> On Aug 31, 2013 6:20 PM, "Brendan Eich" <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
> >
> > Brian Kardell wrote:
> >>
> >>
> >> Fwiw, just bikesheddingly speaking I actually prefer the *.
> >>
> >
> > Let's review. Three reasons for function* syntax:
> >
> > 1. Opt-in required for backward-incompatible definition of 'yield' 
> as low-precedence unary prefix operator.
> >
> > 2. Zero-yield (no yield in body) basis case, useful for delegation 
> via yield* from another generator.
> >
> > 3. Decorator to alert the reader that the body contains yield 
> (ignoring 2 for a moment) reason.
> >
> > You are "bikesheddingly" supporting 3, I take it. Can you say more 
> about why you want a decorator for human readers? Again ignoring 2, 
> which makes the case based on what the JS engine must see, a more 
> "objective" criterion in this case (and, in a different light, in case 1).
> >
> > /be
>
> Yes.  I know its not especially useful
>

No, thanks for commenting.

> and i debated sitting it out (as i often do on this list) - i think #1 
> stands on it own, but I felt that there was some debate about the 
> value of #3 which isn't for compatibility or even function but for 
> developers, and perhaps it might be useful to say that given the 
> choice between * and none, I'd prefer the visual queue
>

("cue" ;-)

> that tells me its different with an easy scan because...It's 
> bikesheddy - i know but I thought it worth saying that as one of those 
> devs I think it has value.  So if we can get 1 and 3 with a single 
> char... Win.
>

Mark makes the case for partial program understanding, so it's not just 
bikeshedding. I sense people are put off by bikeshedding and sometimes 
knee-jerk away from anything resembling it just because syntax is 
involved, but there's more to most issues here than the color of the 
paint on the bikeshed. And of course, once we have the power plant in 
front of the bikeshed operating well, it's fine to argue about the best 
color ;-).

/be
>
> Brendan Eich <mailto:brendan at mozilla.com>
> August 31, 2013 3:19 PM
>
>
> Let's review. Three reasons for function* syntax:
>
> 1. Opt-in required for backward-incompatible definition of 'yield' as 
> low-precedence unary prefix operator.
>
> 2. Zero-yield (no yield in body) basis case, useful for delegation via 
> yield* from another generator.
>
> 3. Decorator to alert the reader that the body contains yield 
> (ignoring 2 for a moment) reason.
>
> You are "bikesheddingly" supporting 3, I take it. Can you say more 
> about why you want a decorator for human readers? Again ignoring 2, 
> which makes the case based on what the JS engine must see, a more 
> "objective" criterion in this case (and, in a different light, in case 
> 1).
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Brian Kardell <mailto:bkardell at gmail.com>
> August 31, 2013 3:11 PM
>
> Fwiw, just bikesheddingly speaking I actually prefer the *.
>
> Brendan Eich <mailto:brendan at mozilla.com>
> August 31, 2013 3:07 PM
> 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.
>
> 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").
>
> 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.
>
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Yuichi Nishiwaki <mailto:yuichi.nishiwaki at gmail.com>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

Brian Kardell <mailto:bkardell at gmail.com> August 31, 2013 4:21 PM

> Yes.  I know its not especially useful

No, thanks for commenting.

> and i debated sitting it out (as i often do on this list) - i think #1 
> stands on it own, but I felt that there was some debate about the 
> value of #3 which isn't for compatibility or even function but for 
> developers, and perhaps it might be useful to say that given the 
> choice between * and none, I'd prefer the visual queue

("cue" ;-)

> that tells me its different with an easy scan because...It's 
> bikesheddy - i know but I thought it worth saying that as one of those 
> devs I think it has value.  So if we can get 1 and 3 with a single 
> char... Win.

Mark makes the case for partial program understanding, so it's not just 
bikeshedding. I sense people are put off by bikeshedding and sometimes 
knee-jerk away from anything resembling it just because syntax is 
involved, but there's more to most issues here than the color of the 
paint on the bikeshed. And of course, once we have the power plant in 
front of the bikeshed operating well, it's fine to argue about the best 
color ;-).

> Brian Kardell <mailto:bkardell at gmail.com> August 31, 2013 4:21 PM

> Yes.  I know its not especially useful

No, thanks for commenting.

> and i debated sitting it out (as i often do on this list) - i think #1 
> stands on it own, but I felt that there was some debate about the 
> value of #3 which isn't for compatibility or even function but for 
> developers, and perhaps it might be useful to say that given the 
> choice between * and none, I'd prefer the visual queue

("cue" ;-)

> that tells me its different with an easy scan because...It's 
> bikesheddy - i know but I thought it worth saying that as one of those 
> devs I think it has value.  So if we can get 1 and 3 with a single 
> char... Win.

Mark makes the case for partial program understanding, so it's not just 
bikeshedding. I sense people are put off by bikeshedding and sometimes 
knee-jerk away from anything resembling it just because syntax is 
involved, but there's more to most issues here than the color of the 
paint on the bikeshed. And of course, once we have the power plant in 
front of the bikeshed operating well, it's fine to argue about the best 
color ;-).