'function *' is not mandatory

Brendan Eich brendan at mozilla.com
Sat Aug 31 17:32:27 PDT 2013

I hope you agree we are beating a dead horse, given my reasons #1 and 2 
require function* -- just checking.

Yuichi Nishiwaki wrote:
> 2013/9/1 Brendan Eich<brendan at mozilla.com>:
>> >  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?

I never wrote "better" about API. The issue is whether, ignoring reasons 
1&2, we help readers by flagging generator functions in their head 
syntax. We do, TC39 has agreed, although some of us feel more strongly 
about this than others (look for my next message, in reply to Allen, 
where I take your side).

So the issue is not "better API deserves syntax", and my point about 
macros was meant to cite languages where the playing field between 
standards bodies and language users who can write macros is leveled, 
precisely because all syntax above the special forms is defined using 

In other words, built-in function* syntax (again ignoring prioritized 
reasons 1&2) in JS is not a judgment about "better", only "necessary 
because predefined". If we could use macros, we would -- and then so 
could other people specifying APIs, developing specific factory function 
contracts, etc.

I hope this makes sense.

> 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*?

Never wrote "evil". Remember, I'm the champion of generators since 2006 
in ES4, when we prototyped them in SpiderMonkey. All without function*, BTW.

> I don't see the reason why you think the latter can be harder to find.

(Stay tuned for my next message.)

>> >  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.

True, and that is worth considering when doubting reason #3. I agree 
with you there.


More information about the es-discuss mailing list