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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
