'function *' is not mandatory
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
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
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