'function *' is not mandatory

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Aug 31 16:51:04 PDT 2013


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. This is particularly clear when you think about GFs as actually being constructors/factories.  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.  A regular Function's body is evaluated before it's call returns.  A GeneratorFunction's body is evaluated sometime after its call returns.  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.   Personally, I would prefer an even stronger marker, such as a different keyword, but * is adequate.  Programming language need to be designed for people. Inferring which functions are GeneratorFunction by the presences of yield may be fine for compilers but it isn't good enough for human readers or writiers.

Allen


More information about the es-discuss mailing list