Allen Wirfs-Brock wrote:
> On Aug 31, 2013, at 3:19 PM, Brendan Eich 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).
>
> I think there is more to #3. The body of a GeneratorFunction has quite different semantics than that of a regular function.

Not necessarily. See Yuichi's reply to Mark.

>   This is particularly clear when you think about GFs as actually being constructors/factories.

Lots of constructors/factories out there. An essential (see Aristotle) 
argument for why function* for generator syntax (ignoring trumping 
reasons 1&2) must say why *this* particular factory needs special (a la 
function*) head syntax.

>    The body of a normal constructor/factory defines what happens before a new instance object is returned to a caller.  The body of a GeneratorFunction defines the future  behavior of the instance object that is returned to the caller.

Functions may diverge (iloop/recurse-to-death). They may contain dead 
code. Yuichi's right, there has to be more to Mark's partial program 
understanding than just whether top-level (balanced) code runs at all, 
if one is making an essential distinction between generator functions 
and other functions.

>    A regular Function's body is evaluated before its call returns.

Yes, generators have an implicit yield; at the top. Now you have hit an 
essential difference with other functions.

>    A GeneratorFunction's body is evaluated sometime after its call returns.

This is ill-stated. You mean a continuation of a yield in its body is 
evaluated, not the whole body (re-)evaluated.

Of course, there may be no yield, or the yield may not be reached. 
Yuichi pointed out similarity with return.

>    This is a critical difference that must to known to a code reader in order to understand any code that includes a GeneratorFunction definition and is more that sufficient to warrant the * sigil.

TC39ers agree but it's good we have reasons 1&2, because consensus on 3 
alone is fragile. Especially with lousy arguing and rehashing resolved 
points (next).

>     Personally, I would prefer an even stronger marker, such as a different keyword,

Please don't rehash. A different keyword breaks use-cases including 
function expressions (remember, we can't use a restricted production 
based on [no LineTerminator here] for 'generator' if it can start an 
arbitrary primary expression).

>   but * is adequate.

It's more than adequate, but I won't rehash. :-|

>    Programming language need to be designed for people.

This begs the question of how Python, Ruby, Lua get by without a head 
sigil. Don't "people" use those languages too? C'mon!

>   Inferring which functions are GeneratorFunction by the presences of yield

This forgets the zero-yield basis case, but nm.

>   may be fine for compilers but it isn't good enough for human readers or writiers.

Python, etc., have human readers and writers.

I'm taking Yuichi's side here not just be argumentative. We need better 
discourse and stronger consensus. Up your game! :-P

/be

Allen Wirfs-Brock wrote:

> I think there is more to #3. The body of a GeneratorFunction has quite different semantics than that of a regular function.

Not necessarily. See Yuichi's reply to Mark.

>   This is particularly clear when you think about GFs as actually being constructors/factories.

Lots of constructors/factories out there. An essential (see Aristotle) 
argument for why `function*` for generator syntax (ignoring trumping 
reasons 1&2) must say why *this* particular factory needs special (a la 
function*) head syntax.

>    The body of a normal constructor/factory defines what happens before a new instance object is returned to a caller.  The body of a GeneratorFunction defines the future  behavior of the instance object that is returned to the caller.

Functions may diverge (iloop/recurse-to-death). They may contain dead 
code. Yuichi's right, there has to be more to Mark's partial program 
understanding than just whether top-level (balanced) code runs at all, 
if one is making an essential distinction between generator functions 
and other functions.

>    A regular Function's body is evaluated before its call returns.

Yes, generators have an implicit yield; at the top. Now you have hit an 
essential difference with other functions.

>    A GeneratorFunction's body is evaluated sometime after its call returns.

This is ill-stated. You mean a continuation of a yield in its body is 
evaluated, not the whole body (re-)evaluated.

Of course, there may be no yield, or the yield may not be reached. 
Yuichi pointed out similarity with return.

>    This is a critical difference that must to known to a code reader in order to understand any code that includes a GeneratorFunction definition and is more that sufficient to warrant the * sigil.

TC39ers agree but it's good we have reasons 1&2, because consensus on 3 
alone is fragile. Especially with lousy arguing and rehashing resolved 
points (next).

>     Personally, I would prefer an even stronger marker, such as a different keyword,

Please don't rehash. A different keyword breaks use-cases including 
function expressions (remember, we can't use a restricted production 
based on [no LineTerminator here] for 'generator' if it can start an 
arbitrary primary expression).

>   but * is adequate.

It's more than adequate, but I won't rehash. :-|

>    Programming language need to be designed for people.

This begs the question of how Python, Ruby, Lua get by without a head 
sigil. Don't "people" use those languages too? C'mon!

>   Inferring which functions are GeneratorFunction by the presences of yield

This forgets the zero-yield basis case, but nm.

>   may be fine for compilers but it isn't good enough for human readers or writiers.

Python, etc., have human readers and writers.

I'm taking Yuichi's side here not just be argumentative. We need better 
discourse and stronger consensus. Up your game! :-P