'function *' is not mandatory

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

'function *' is not mandatory

Yuichi Nishiwaki
Hi all, I just found a post that the current generator syntax
(function *) seems have decided in:

https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html

According to the post, the biggest reason the star syntax is adopted
for now is that you cannot write empty generators with star-less
functions in a consistent simple way. But the situation has changed,
and in the current spec (rev 17) yield* is now capable of taking any
kind of iterator, so you can make empty generators just like

```js
function * () {
    yield * [];
}
```

This looks enough good and simple at least to me. And I wonder if even
now generators still need to be declared with 'star's. What are the
advantages of 'star'ed generators rather than 'star'-lesses? If not
exist, shouldn't it be removed (for the simplicity)?

Thank you.

--
Yuichi Nishiwaki
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brendan Eich-3
The empty-body basis case is one reason. A stronger reason is that yield
is not a reserved identifier, and it is used in existing content, so
function* allows contextual reservation without breaking backward
compatibility.

Another reason is to clue readers in early, when reading in source
order, that this function is a generator, in the case where yield usage
in the function's body is somewhat hard to see at a glance.

/be

> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:15 PM
> Hi all, I just found a post that the current generator syntax
> (function *) seems have decided in:
>
> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>
> According to the post, the biggest reason the star syntax is adopted
> for now is that you cannot write empty generators with star-less
> functions in a consistent simple way. But the situation has changed,
> and in the current spec (rev 17) yield* is now capable of taking any
> kind of iterator, so you can make empty generators just like
>
> ```js
> function * () {
> yield * [];
> }
> ```
>
> This looks enough good and simple at least to me. And I wonder if even
> now generators still need to be declared with 'star's. What are the
> advantages of 'star'ed generators rather than 'star'-lesses? If not
> exist, shouldn't it be removed (for the simplicity)?
>
> Thank you.
>
> --
> Yuichi Nishiwaki
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Oliver Hunt-2
In reply to this post by Yuichi Nishiwaki

On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki <[hidden email]> wrote:

> Hi all, I just found a post that the current generator syntax
> (function *) seems have decided in:
>
> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>
> According to the post, the biggest reason the star syntax is adopted
> for now is that you cannot write empty generators with star-less
> functions in a consistent simple way. But the situation has changed,
> and in the current spec (rev 17) yield* is now capable of taking any
> kind of iterator, so you can make empty generators just like
>
> ```js
> function * () {
>    yield * [];
> }
> ```
>
> This looks enough good and simple at least to me. And I wonder if even
> now generators still need to be declared with 'star's. What are the
> advantages of 'star'ed generators rather than 'star'-lesses? If not
> exist, shouldn't it be removed (for the simplicity)?
>

The reason for the * is substantially (IIRC) to make it possible for an engine
to help prevent developers from unintentionally creating a generator function,
and to make it possible for someone attempting to use a function to identify immediately
whether it is a generator or a regular function.

--Oliver

> Thank you.
>
> --
> Yuichi Nishiwaki
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Yuichi Nishiwaki
In reply to this post by Brendan Eich-3
ES5 specifies "yield" as a reserved keyword, right? So there should be
no need to make it contextual.

2013/9/1 Brendan Eich <[hidden email]>:

> The empty-body basis case is one reason. A stronger reason is that yield is
> not a reserved identifier, and it is used in existing content, so function*
> allows contextual reservation without breaking backward compatibility.
>
> Another reason is to clue readers in early, when reading in source order,
> that this function is a generator, in the case where yield usage in the
> function's body is somewhat hard to see at a glance.
>
> /be
>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 12:15 PM
>>
>> Hi all, I just found a post that the current generator syntax
>> (function *) seems have decided in:
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>
>> According to the post, the biggest reason the star syntax is adopted
>> for now is that you cannot write empty generators with star-less
>> functions in a consistent simple way. But the situation has changed,
>> and in the current spec (rev 17) yield* is now capable of taking any
>> kind of iterator, so you can make empty generators just like
>>
>> ```js
>> function * () {
>> yield * [];
>> }
>> ```
>>
>> This looks enough good and simple at least to me. And I wonder if even
>> now generators still need to be declared with 'star's. What are the
>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> exist, shouldn't it be removed (for the simplicity)?
>>
>> Thank you.
>>
>> --
>> Yuichi Nishiwaki
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brendan Eich-3
> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:45 PM
> ES5 specifies "yield" as a reserved keyword, right?

Wrong, only ES5 strict reserved "yield".

> So there should be
> no need to make it contextual.
>
There is; when we first tried reserving "yield" in 2006, we had to put
it behind opt-in versioning because content used "yield" as an
unqualified identifier. IIRC it's still used.

Backward compatibility is what it is. "use strict"; in ES5 was an
opt-in, so not widely adopted enough (i.e., universally adopted) to help.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Yuichi Nishiwaki
In reply to this post by Oliver Hunt-2
I can't get the point, why you need to know if the function is a
generator or not at a glance?

1. Forcing users to mark the function as a generator is only a
duplication. It basically doesn't have any meaning other than
double-checking, and fundamental risk for the unintentional creation
is still not removed.
2. Even if you know the function is a generator in early, you still
need to read the entire source code to get the information about what
the generator yields and when it stops.

2013/9/1 Oliver Hunt <[hidden email]>:

>
> On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki <[hidden email]> wrote:
>
>> Hi all, I just found a post that the current generator syntax
>> (function *) seems have decided in:
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>
>> According to the post, the biggest reason the star syntax is adopted
>> for now is that you cannot write empty generators with star-less
>> functions in a consistent simple way. But the situation has changed,
>> and in the current spec (rev 17) yield* is now capable of taking any
>> kind of iterator, so you can make empty generators just like
>>
>> ```js
>> function * () {
>>    yield * [];
>> }
>> ```
>>
>> This looks enough good and simple at least to me. And I wonder if even
>> now generators still need to be declared with 'star's. What are the
>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> exist, shouldn't it be removed (for the simplicity)?
>>
>
> The reason for the * is substantially (IIRC) to make it possible for an engine
> to help prevent developers from unintentionally creating a generator function,
> and to make it possible for someone attempting to use a function to identify immediately
> whether it is a generator or a regular function.
>
> --Oliver
>
>> Thank you.
>>
>> --
>> Yuichi Nishiwaki
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brendan Eich-3
Let's not go in circles -- the primary reason for function* is because
yield is not reserved in JS and is used by web content as a plain
identifier. It is a low-precedence unary prefix operator, so cannot be
contextually reserved by a grammatical restriction as "module" can. It
needs opt-in syntax.

Separately, some on TC39 want a flag on the function, in the head
syntax, to alert readers to the generator. That's a secondary reason,
independent and not as strong in my view.

There's nothing to "get" or "not get" about backward compatbility. It
just "is". :-|

/be

> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:55 PM
> I can't get the point, why you need to know if the function is a
> generator or not at a glance?
>
> 1. Forcing users to mark the function as a generator is only a
> duplication. It basically doesn't have any meaning other than
> double-checking, and fundamental risk for the unintentional creation
> is still not removed.
> 2. Even if you know the function is a generator in early, you still
> need to read the entire source code to get the information about what
> the generator yields and when it stops.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Oliver Hunt <mailto:[hidden email]>
> August 31, 2013 12:25 PM
> On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki<[hidden email]>  wrote:
>
>> Hi all, I just found a post that the current generator syntax
>> (function *) seems have decided in:
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>
>> According to the post, the biggest reason the star syntax is adopted
>> for now is that you cannot write empty generators with star-less
>> functions in a consistent simple way. But the situation has changed,
>> and in the current spec (rev 17) yield* is now capable of taking any
>> kind of iterator, so you can make empty generators just like
>>
>> ```js
>> function * () {
>>     yield * [];
>> }
>> ```
>>
>> This looks enough good and simple at least to me. And I wonder if even
>> now generators still need to be declared with 'star's. What are the
>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> exist, shouldn't it be removed (for the simplicity)?
>>
>
> The reason for the * is substantially (IIRC) to make it possible for an engine
> to help prevent developers from unintentionally creating a generator function,
> and to make it possible for someone attempting to use a function to identify immediately
> whether it is a generator or a regular function.
>
> --Oliver
>
>> Thank you.
>>
>> --
>> Yuichi Nishiwaki
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:15 PM
> Hi all, I just found a post that the current generator syntax
> (function *) seems have decided in:
>
> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>
> According to the post, the biggest reason the star syntax is adopted
> for now is that you cannot write empty generators with star-less
> functions in a consistent simple way. But the situation has changed,
> and in the current spec (rev 17) yield* is now capable of taking any
> kind of iterator, so you can make empty generators just like
>
> ```js
> function * () {
> yield * [];
> }
> ```
>
> This looks enough good and simple at least to me. And I wonder if even
> now generators still need to be declared with 'star's. What are the
> advantages of 'star'ed generators rather than 'star'-lesses? If not
> exist, shouldn't it be removed (for the simplicity)?
>
> Thank you.
>
> --
> Yuichi Nishiwaki
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Yuichi Nishiwaki
OK, right. I understand my first propose does not work. :-|
So one more question is how about making '*' optional in strict mode?
(Should I separate the topic to another?)

2013/9/1 Brendan Eich <[hidden email]>:

> Let's not go in circles -- the primary reason for function* is because yield
> is not reserved in JS and is used by web content as a plain identifier. It
> is a low-precedence unary prefix operator, so cannot be contextually
> reserved by a grammatical restriction as "module" can. It needs opt-in
> syntax.
>
> Separately, some on TC39 want a flag on the function, in the head syntax, to
> alert readers to the generator. That's a secondary reason, independent and
> not as strong in my view.
>
> There's nothing to "get" or "not get" about backward compatbility. It just
> "is". :-|
>
> /be
>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 12:55 PM
>>
>> I can't get the point, why you need to know if the function is a
>> generator or not at a glance?
>>
>> 1. Forcing users to mark the function as a generator is only a
>> duplication. It basically doesn't have any meaning other than
>> double-checking, and fundamental risk for the unintentional creation
>> is still not removed.
>> 2. Even if you know the function is a generator in early, you still
>> need to read the entire source code to get the information about what
>> the generator yields and when it stops.
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Oliver Hunt <mailto:[hidden email]>
>> August 31, 2013 12:25 PM
>>
>> On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki<[hidden email]>
>> wrote:
>>
>>> Hi all, I just found a post that the current generator syntax
>>> (function *) seems have decided in:
>>>
>>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>>
>>> According to the post, the biggest reason the star syntax is adopted
>>> for now is that you cannot write empty generators with star-less
>>> functions in a consistent simple way. But the situation has changed,
>>> and in the current spec (rev 17) yield* is now capable of taking any
>>> kind of iterator, so you can make empty generators just like
>>>
>>> ```js
>>> function * () {
>>>     yield * [];
>>> }
>>> ```
>>>
>>> This looks enough good and simple at least to me. And I wonder if even
>>> now generators still need to be declared with 'star's. What are the
>>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>>> exist, shouldn't it be removed (for the simplicity)?
>>>
>>
>> The reason for the * is substantially (IIRC) to make it possible for an
>> engine
>> to help prevent developers from unintentionally creating a generator
>> function,
>> and to make it possible for someone attempting to use a function to
>> identify immediately
>> whether it is a generator or a regular function.
>>
>> --Oliver
>>
>>> Thank you.
>>>
>>> --
>>> Yuichi Nishiwaki
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 12:15 PM
>>
>> Hi all, I just found a post that the current generator syntax
>> (function *) seems have decided in:
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>
>> According to the post, the biggest reason the star syntax is adopted
>> for now is that you cannot write empty generators with star-less
>> functions in a consistent simple way. But the situation has changed,
>> and in the current spec (rev 17) yield* is now capable of taking any
>> kind of iterator, so you can make empty generators just like
>>
>> ```js
>> function * () {
>> yield * [];
>> }
>> ```
>>
>> This looks enough good and simple at least to me. And I wonder if even
>> now generators still need to be declared with 'star's. What are the
>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> exist, shouldn't it be removed (for the simplicity)?
>>
>> Thank you.
>>
>> --
>> Yuichi Nishiwaki
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Mark S. Miller-2
On Sat, Aug 31, 2013 at 1:14 PM, Yuichi Nishiwaki <[hidden email]> wrote:
OK, right. I understand my first propose does not work. :-|
So one more question is how about making '*' optional in strict mode?
(Should I separate the topic to another?)

2013/9/1 Brendan Eich <[hidden email]>:
> Let's not go in circles -- the primary reason for function* is because yield
> is not reserved in JS and is used by web content as a plain identifier. It
> is a low-precedence unary prefix operator, so cannot be contextually
> reserved by a grammatical restriction as "module" can. It needs opt-in
> syntax.
>
> Separately, some on TC39 want a flag on the function, in the head syntax, to
> alert readers to the generator. That's a secondary reason, independent and
> not as strong in my view.

I am one of those on TC39 that want the visible flag. Since, in my view, the only non-mistaken need to preserve sloppy mode is as an ES3 compatibility mode and ES3 has no generators, I consider this flagging issue to be the important one. Yes, you have to read the function to know *what* it generates. But even before you've figured that out, your whole effort to read the function is different once you know you're reading a generator function. Better to know it early.

Code is read much more than it is written -- at least code that matters.


 
>
> There's nothing to "get" or "not get" about backward compatbility. It just
> "is". :-|
>
> /be
>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 12:55 PM
>>
>> I can't get the point, why you need to know if the function is a
>> generator or not at a glance?
>>
>> 1. Forcing users to mark the function as a generator is only a
>> duplication. It basically doesn't have any meaning other than
>> double-checking, and fundamental risk for the unintentional creation
>> is still not removed.
>> 2. Even if you know the function is a generator in early, you still
>> need to read the entire source code to get the information about what
>> the generator yields and when it stops.
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Oliver Hunt <mailto:[hidden email]>
>> August 31, 2013 12:25 PM
>>
>> On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki<[hidden email]>
>> wrote:
>>
>>> Hi all, I just found a post that the current generator syntax
>>> (function *) seems have decided in:
>>>
>>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>>
>>> According to the post, the biggest reason the star syntax is adopted
>>> for now is that you cannot write empty generators with star-less
>>> functions in a consistent simple way. But the situation has changed,
>>> and in the current spec (rev 17) yield* is now capable of taking any
>>> kind of iterator, so you can make empty generators just like
>>>
>>> ```js
>>> function * () {
>>>     yield * [];
>>> }
>>> ```
>>>
>>> This looks enough good and simple at least to me. And I wonder if even
>>> now generators still need to be declared with 'star's. What are the
>>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>>> exist, shouldn't it be removed (for the simplicity)?
>>>
>>
>> The reason for the * is substantially (IIRC) to make it possible for an
>> engine
>> to help prevent developers from unintentionally creating a generator
>> function,
>> and to make it possible for someone attempting to use a function to
>> identify immediately
>> whether it is a generator or a regular function.
>>
>> --Oliver
>>
>>> Thank you.
>>>
>>> --
>>> Yuichi Nishiwaki
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 12:15 PM
>>
>> Hi all, I just found a post that the current generator syntax
>> (function *) seems have decided in:
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>
>> According to the post, the biggest reason the star syntax is adopted
>> for now is that you cannot write empty generators with star-less
>> functions in a consistent simple way. But the situation has changed,
>> and in the current spec (rev 17) yield* is now capable of taking any
>> kind of iterator, so you can make empty generators just like
>>
>> ```js
>> function * () {
>> yield * [];
>> }
>> ```
>>
>> This looks enough good and simple at least to me. And I wonder if even
>> now generators still need to be declared with 'star's. What are the
>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> exist, shouldn't it be removed (for the simplicity)?
>>
>> Thank you.
>>
>> --
>> Yuichi Nishiwaki
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brendan Eich-3
In reply to this post by Yuichi Nishiwaki
Mark's reply helps, but I want to add that we are *not* making
gratuitous differences between strict and non-strict mode. Modes are
bad, one is more than enough. Further speciation in later editions just
makes more. Just say no, write that * after function, and get on with
life :-).

/be

> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 1:14 PM
> OK, right. I understand my first propose does not work. :-|
> So one more question is how about making '*' optional in strict mode?
> (Should I separate the topic to another?)
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Brendan Eich <mailto:[hidden email]>
> August 31, 2013 12:58 PM
> Let's not go in circles -- the primary reason for function* is because
> yield is not reserved in JS and is used by web content as a plain
> identifier. It is a low-precedence unary prefix operator, so cannot be
> contextually reserved by a grammatical restriction as "module" can. It
> needs opt-in syntax.
>
> Separately, some on TC39 want a flag on the function, in the head
> syntax, to alert readers to the generator. That's a secondary reason,
> independent and not as strong in my view.
>
> There's nothing to "get" or "not get" about backward compatbility. It
> just "is". :-|
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:55 PM
> I can't get the point, why you need to know if the function is a
> generator or not at a glance?
>
> 1. Forcing users to mark the function as a generator is only a
> duplication. It basically doesn't have any meaning other than
> double-checking, and fundamental risk for the unintentional creation
> is still not removed.
> 2. Even if you know the function is a generator in early, you still
> need to read the entire source code to get the information about what
> the generator yields and when it stops.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Oliver Hunt <mailto:[hidden email]>
> August 31, 2013 12:25 PM
> On Aug 31, 2013, at 12:15 PM, Yuichi Nishiwaki<[hidden email]>  wrote:
>
>> Hi all, I just found a post that the current generator syntax
>> (function *) seems have decided in:
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>
>> According to the post, the biggest reason the star syntax is adopted
>> for now is that you cannot write empty generators with star-less
>> functions in a consistent simple way. But the situation has changed,
>> and in the current spec (rev 17) yield* is now capable of taking any
>> kind of iterator, so you can make empty generators just like
>>
>> ```js
>> function * () {
>>     yield * [];
>> }
>> ```
>>
>> This looks enough good and simple at least to me. And I wonder if even
>> now generators still need to be declared with 'star's. What are the
>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> exist, shouldn't it be removed (for the simplicity)?
>>
>
> The reason for the * is substantially (IIRC) to make it possible for an engine
> to help prevent developers from unintentionally creating a generator function,
> and to make it possible for someone attempting to use a function to identify immediately
> whether it is a generator or a regular function.
>
> --Oliver
>
>> Thank you.
>>
>> --
>> Yuichi Nishiwaki
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:15 PM
> Hi all, I just found a post that the current generator syntax
> (function *) seems have decided in:
>
> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>
> According to the post, the biggest reason the star syntax is adopted
> for now is that you cannot write empty generators with star-less
> functions in a consistent simple way. But the situation has changed,
> and in the current spec (rev 17) yield* is now capable of taking any
> kind of iterator, so you can make empty generators just like
>
> ```js
> function * () {
> yield * [];
> }
> ```
>
> This looks enough good and simple at least to me. And I wonder if even
> now generators still need to be declared with 'star's. What are the
> advantages of 'star'ed generators rather than 'star'-lesses? If not
> exist, shouldn't it be removed (for the simplicity)?
>
> Thank you.
>
> --
> Yuichi Nishiwaki
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Claus Reinke
In reply to this post by Mark S. Miller-2
> I am one of those on TC39 that want the visible flag. Since, in my view,
> the only non-mistaken need to preserve sloppy mode is as an ES3
> compatibility mode and ES3 has no generators, I consider this flagging
> issue to be the important one. Yes, you have to read the function to know
> *what* it generates. But even before you've figured that out, your whole
> effort to read the function is different once you know you're reading a
> generator function. Better to know it early.

But that is a *semantic* property - you can't force it into *syntax*.

Consider this code:

    // run with node --harmony
    function* gen() { yield 1 }
    function f(g) { return g() }
    console.log( f(gen).next() ); // { value: 1, done: false }

You can't see by looking at 'f' that it can return an iterator. And 'f's
parameter and return value could even vary dynamically.

I could imagine a type system for this, which would be nice (just as it
would be nice to have a type system telling you whether a callback-taking
function uses the callback async, sync, or both). Then your IDE could tell
you (an approximation of) what you're dealing with, providing verified
API documentation. But I don't see how to do that with syntactic tools only.

> Code is read much more than it is written -- at least code that matters.

For this reason, I would still suggest to separate generators from 'function' -
there is nothing function-specific about generators (apart from generator
implementations using stack frames, perhaps), so I find it confusing to
mix up these two concepts. It also keeps us from using arrow functions
freely with generators.

I did suggest using something like 'do* { yield 1 }' as generator syntax
(ie, 'do*{}' would be an expression denoting an iterable, and 'yield' could
only appear in 'do*{}'). It still has the syntactic flag, but it separates functions
and generators. We could then recombine the two as needed, without
complicating the 'function'-related specification machinery:

    let gen = v => do* { yield v };
    gen(1).next()    // { value: 1, done: false }

Claus
 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Yuichi Nishiwaki
In reply to this post by Mark S. Miller-2
I get the point. Indeed. Modes are a kind of magic...

Regarding the secondary reason:
I don't understand the "difference" well, could you explain in detail?
You know, all other languages that are dynamically typed and have
generators, such as python, lua, and even JavaScript 1.8 don't
distinguish two kinds of the functions.
I guess this directly means that there isn't something different as
you said (because they all have more or less made successful).
And in my personal view, yield is something that can be generalized
together with return, like

- return: discards the succeeding partial continuation there
- yield: preserve the succeeding partial continuation there

It is very clear in a sense, I believe. So my guess is that the
strangeness yields have is a mater of getting used to, and that it is
much more natural to treat two of them as a same thing.

2013/9/1 Mark S. Miller <[hidden email]>:

> On Sat, Aug 31, 2013 at 1:14 PM, Yuichi Nishiwaki
> <[hidden email]> wrote:
>>
>> OK, right. I understand my first propose does not work. :-|
>> So one more question is how about making '*' optional in strict mode?
>> (Should I separate the topic to another?)
>>
>> 2013/9/1 Brendan Eich <[hidden email]>:
>> > Let's not go in circles -- the primary reason for function* is because
>> > yield
>> > is not reserved in JS and is used by web content as a plain identifier.
>> > It
>> > is a low-precedence unary prefix operator, so cannot be contextually
>> > reserved by a grammatical restriction as "module" can. It needs opt-in
>> > syntax.
>> >
>> > Separately, some on TC39 want a flag on the function, in the head
>> > syntax, to
>> > alert readers to the generator. That's a secondary reason, independent
>> > and
>> > not as strong in my view.
>
>
> I am one of those on TC39 that want the visible flag. Since, in my view, the
> only non-mistaken need to preserve sloppy mode is as an ES3 compatibility
> mode and ES3 has no generators, I consider this flagging issue to be the
> important one. Yes, you have to read the function to know *what* it
> generates. But even before you've figured that out, your whole effort to
> read the function is different once you know you're reading a generator
> function. Better to know it early.
>
> Code is read much more than it is written -- at least code that matters.
>
>
>
>>
>> >
>> > There's nothing to "get" or "not get" about backward compatbility. It
>> > just
>> > "is". :-|
>> >
>> > /be
>> >
>> >> Yuichi Nishiwaki <mailto:[hidden email]>
>> >> August 31, 2013 12:55 PM
>> >>
>> >> I can't get the point, why you need to know if the function is a
>> >> generator or not at a glance?
>> >>
>> >> 1. Forcing users to mark the function as a generator is only a
>> >> duplication. It basically doesn't have any meaning other than
>> >> double-checking, and fundamental risk for the unintentional creation
>> >> is still not removed.
>> >> 2. Even if you know the function is a generator in early, you still
>> >> need to read the entire source code to get the information about what
>> >> the generator yields and when it stops.
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >> Oliver Hunt <mailto:[hidden email]>
>> >> August 31, 2013 12:25 PM
>> >>
>> >> On Aug 31, 2013, at 12:15 PM, Yuichi
>> >> Nishiwaki<[hidden email]>
>> >> wrote:
>> >>
>> >>> Hi all, I just found a post that the current generator syntax
>> >>> (function *) seems have decided in:
>> >>>
>> >>> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>> >>>
>> >>> According to the post, the biggest reason the star syntax is adopted
>> >>> for now is that you cannot write empty generators with star-less
>> >>> functions in a consistent simple way. But the situation has changed,
>> >>> and in the current spec (rev 17) yield* is now capable of taking any
>> >>> kind of iterator, so you can make empty generators just like
>> >>>
>> >>> ```js
>> >>> function * () {
>> >>>     yield * [];
>> >>> }
>> >>> ```
>> >>>
>> >>> This looks enough good and simple at least to me. And I wonder if even
>> >>> now generators still need to be declared with 'star's. What are the
>> >>> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> >>> exist, shouldn't it be removed (for the simplicity)?
>> >>>
>> >>
>> >> The reason for the * is substantially (IIRC) to make it possible for an
>> >> engine
>> >> to help prevent developers from unintentionally creating a generator
>> >> function,
>> >> and to make it possible for someone attempting to use a function to
>> >> identify immediately
>> >> whether it is a generator or a regular function.
>> >>
>> >> --Oliver
>> >>
>> >>> Thank you.
>> >>>
>> >>> --
>> >>> Yuichi Nishiwaki
>> >>> _______________________________________________
>> >>> es-discuss mailing list
>> >>> [hidden email]
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >> Yuichi Nishiwaki <mailto:[hidden email]>
>> >> August 31, 2013 12:15 PM
>> >>
>> >> Hi all, I just found a post that the current generator syntax
>> >> (function *) seems have decided in:
>> >>
>> >> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>> >>
>> >> According to the post, the biggest reason the star syntax is adopted
>> >> for now is that you cannot write empty generators with star-less
>> >> functions in a consistent simple way. But the situation has changed,
>> >> and in the current spec (rev 17) yield* is now capable of taking any
>> >> kind of iterator, so you can make empty generators just like
>> >>
>> >> ```js
>> >> function * () {
>> >> yield * [];
>> >> }
>> >> ```
>> >>
>> >> This looks enough good and simple at least to me. And I wonder if even
>> >> now generators still need to be declared with 'star's. What are the
>> >> advantages of 'star'ed generators rather than 'star'-lesses? If not
>> >> exist, shouldn't it be removed (for the simplicity)?
>> >>
>> >> Thank you.
>> >>
>> >> --
>> >> Yuichi Nishiwaki
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
>     Cheers,
>     --MarkM
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brendan Eich-3
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.

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

You might think of function* as decorator syntax. It's important, given
the 'yield' backward compatibility issue, not to make the syntax too
heavyweight. One character is as minimal as we can get.

But now I'm just shoring up the argument based on compatibility. You'll
have to get Mark or someone else to help you understand their particular
argument that the function head needs decoration to alert the reader to
the possible (not required) presence of yield in the body.

Note also the empty-body basis case -- that's a good argument for
function* independent from the backward-compatibility and
good-for-readers arguments.

/be

> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 2:12 PM
> I get the point. Indeed. Modes are a kind of magic...
>
> Regarding the secondary reason:
> I don't understand the "difference" well, could you explain in detail?
> You know, all other languages that are dynamically typed and have
> generators, such as python, lua, and even JavaScript 1.8 don't
> distinguish two kinds of the functions.
> I guess this directly means that there isn't something different as
> you said (because they all have more or less made successful).
> And in my personal view, yield is something that can be generalized
> together with return, like
>
> - return: discards the succeeding partial continuation there
> - yield: preserve the succeeding partial continuation there
>
> It is very clear in a sense, I believe. So my guess is that the
> strangeness yields have is a mater of getting used to, and that it is
> much more natural to treat two of them as a same thing.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Mark S. Miller <mailto:[hidden email]>
> August 31, 2013 1:33 PM
> On Sat, Aug 31, 2013 at 1:14 PM, Yuichi Nishiwaki
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     OK, right. I understand my first propose does not work. :-|
>     So one more question is how about making '*' optional in strict mode?
>     (Should I separate the topic to another?)
>
>     2013/9/1 Brendan Eich <[hidden email]
>     <mailto:[hidden email]>>:
>     > Let's not go in circles -- the primary reason for function* is
>     because yield
>     > is not reserved in JS and is used by web content as a plain
>     identifier. It
>     > is a low-precedence unary prefix operator, so cannot be contextually
>     > reserved by a grammatical restriction as "module" can. It needs
>     opt-in
>     > syntax.
>     >
>     > Separately, some on TC39 want a flag on the function, in the
>     head syntax, to
>     > alert readers to the generator. That's a secondary reason,
>     independent and
>     > not as strong in my view.
>
>
> I am one of those on TC39 that want the visible flag. Since, in my
> view, the only non-mistaken need to preserve sloppy mode is as an ES3
> compatibility mode and ES3 has no generators, I consider this flagging
> issue to be the important one. Yes, you have to read the function to
> know *what* it generates. But even before you've figured that out,
> your whole effort to read the function is different once you know
> you're reading a generator function. Better to know it early.
>
> Code is read much more than it is written -- at least code that matters.
>
>
>     >
>     > There's nothing to "get" or "not get" about backward
>     compatbility. It just
>     > "is". :-|
>     >
>     > /be
>     >
>     >> Yuichi Nishiwaki <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >> August 31, 2013 12:55 PM
>     >>
>     >> I can't get the point, why you need to know if the function is a
>     >> generator or not at a glance?
>     >>
>     >> 1. Forcing users to mark the function as a generator is only a
>     >> duplication. It basically doesn't have any meaning other than
>     >> double-checking, and fundamental risk for the unintentional
>     creation
>     >> is still not removed.
>     >> 2. Even if you know the function is a generator in early, you still
>     >> need to read the entire source code to get the information
>     about what
>     >> the generator yields and when it stops.
>     >> _______________________________________________
>     >> es-discuss mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://mail.mozilla.org/listinfo/es-discuss
>     >>
>     >> Oliver Hunt <mailto:[hidden email] <mailto:[hidden email]>>
>     >> August 31, 2013 12:25 PM
>     >>
>     >> On Aug 31, 2013, at 12:15 PM, Yuichi
>     Nishiwaki<[hidden email]
>     <mailto:[hidden email]>>
>     >> wrote:
>     >>
>     >>> Hi all, I just found a post that the current generator syntax
>     >>> (function *) seems have decided in:
>     >>>
>     >>>
>     https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>     >>>
>     >>> According to the post, the biggest reason the star syntax is
>     adopted
>     >>> for now is that you cannot write empty generators with star-less
>     >>> functions in a consistent simple way. But the situation has
>     changed,
>     >>> and in the current spec (rev 17) yield* is now capable of
>     taking any
>     >>> kind of iterator, so you can make empty generators just like
>     >>>
>     >>> ```js
>     >>> function * () {
>     >>>     yield * [];
>     >>> }
>     >>> ```
>     >>>
>     >>> This looks enough good and simple at least to me. And I wonder
>     if even
>     >>> now generators still need to be declared with 'star's. What
>     are the
>     >>> advantages of 'star'ed generators rather than 'star'-lesses?
>     If not
>     >>> exist, shouldn't it be removed (for the simplicity)?
>     >>>
>     >>
>     >> The reason for the * is substantially (IIRC) to make it
>     possible for an
>     >> engine
>     >> to help prevent developers from unintentionally creating a
>     generator
>     >> function,
>     >> and to make it possible for someone attempting to use a function to
>     >> identify immediately
>     >> whether it is a generator or a regular function.
>     >>
>     >> --Oliver
>     >>
>     >>> Thank you.
>     >>>
>     >>> --
>     >>> Yuichi Nishiwaki
>     >>> _______________________________________________
>     >>> es-discuss mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     >>> https://mail.mozilla.org/listinfo/es-discuss
>     >>
>     >>
>     >> _______________________________________________
>     >> es-discuss mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://mail.mozilla.org/listinfo/es-discuss
>     >>
>     >> Yuichi Nishiwaki <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >> August 31, 2013 12:15 PM
>     >>
>     >> Hi all, I just found a post that the current generator syntax
>     >> (function *) seems have decided in:
>     >>
>     >> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>     >>
>     >> According to the post, the biggest reason the star syntax is
>     adopted
>     >> for now is that you cannot write empty generators with star-less
>     >> functions in a consistent simple way. But the situation has
>     changed,
>     >> and in the current spec (rev 17) yield* is now capable of
>     taking any
>     >> kind of iterator, so you can make empty generators just like
>     >>
>     >> ```js
>     >> function * () {
>     >> yield * [];
>     >> }
>     >> ```
>     >>
>     >> This looks enough good and simple at least to me. And I wonder
>     if even
>     >> now generators still need to be declared with 'star's. What are the
>     >> advantages of 'star'ed generators rather than 'star'-lesses? If not
>     >> exist, shouldn't it be removed (for the simplicity)?
>     >>
>     >> Thank you.
>     >>
>     >> --
>     >> Yuichi Nishiwaki
>     >> _______________________________________________
>     >> es-discuss mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://mail.mozilla.org/listinfo/es-discuss
>     >>
>     >
>     _______________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 1:14 PM
> OK, right. I understand my first propose does not work. :-|
> So one more question is how about making '*' optional in strict mode?
> (Should I separate the topic to another?)
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Brendan Eich <mailto:[hidden email]>
> August 31, 2013 12:58 PM
> Let's not go in circles -- the primary reason for function* is because
> yield is not reserved in JS and is used by web content as a plain
> identifier. It is a low-precedence unary prefix operator, so cannot be
> contextually reserved by a grammatical restriction as "module" can. It
> needs opt-in syntax.
>
> Separately, some on TC39 want a flag on the function, in the head
> syntax, to alert readers to the generator. That's a secondary reason,
> independent and not as strong in my view.
>
> There's nothing to "get" or "not get" about backward compatbility. It
> just "is". :-|
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Yuichi Nishiwaki <mailto:[hidden email]>
> August 31, 2013 12:55 PM
> I can't get the point, why you need to know if the function is a
> generator or not at a glance?
>
> 1. Forcing users to mark the function as a generator is only a
> duplication. It basically doesn't have any meaning other than
> double-checking, and fundamental risk for the unintentional creation
> is still not removed.
> 2. Even if you know the function is a generator in early, you still
> need to read the entire source code to get the information about what
> the generator yields and when it stops.
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brian Kardell

Fwiw, just bikesheddingly speaking I actually prefer the *.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brendan Eich-3
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).

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Mark S. Miller-2
In reply to this post by Yuichi Nishiwaki
On Sat, Aug 31, 2013 at 2:12 PM, Yuichi Nishiwaki <[hidden email]> wrote:
I get the point. Indeed. Modes are a kind of magic...

Regarding the secondary reason:
I don't understand the "difference" well, could you explain in detail?


  function f(....) {
    // .... code sequence 1

    // .... balanced code sequence 2

    // .... code sequence 3
  }

Without looking at f's parameters, code sequence 1, or code sequence 3, the reader knows that code sequence 2 will execute some number of times, perhaps 0, only during the turn in which f is called and before f returns. Once f's caller gets control again, code sequence 2 will no longer ever execute as part of that call to f.  The only contextual knowledge the reader needs in order to know this is that there are no intermediate function definitions within f wrapping code sequence 2 -- i.e., that code sequence 2 is code of the function f itself, as opposed to code of a function within function a. It suffices to check that there are no unbalanced function definition starts in code sequence 1. Beyond this "is it wrapped in a function" question, the reader doesn't even care if code sequence 1 starts a control structure wrapping code sequence 2, that is closed in code sequence 3.

If the header says |function*|, then the reader knows that they do not know all this, and a more careful read is needed to understand when code sequence 2 might execute as part of a given call to f after f's caller resumes.

See <http://erights.org/data/irrelevance.html> on the need to do partial reasoning about code fragments. I find it frustrating that there so little computer science devoted to the cognitive load required of such partial program understanding tasks. This properly should be part of the study of "notation as user interface".

 
You know, all other languages that are dynamically typed and have
generators, such as python, lua, and even JavaScript 1.8 don't
distinguish two kinds of the functions.
I guess this directly means that there isn't something different as
you said (because they all have more or less made successful).
And in my personal view, yield is something that can be generalized
together with return, like

- return: discards the succeeding partial continuation there
- yield: preserve the succeeding partial continuation there

It is very clear in a sense, I believe. So my guess is that the
strangeness yields have is a mater of getting used to, and that it is
much more natural to treat two of them as a same thing.
--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Yuichi Nishiwaki
In reply to this post by Brendan Eich-3
2013/9/1 Brendan Eich <[hidden email]>:
> 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?
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*?
I don't see the reason why you think the latter can be harder to find.

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

> You might think of function* as decorator syntax. It's important, given the
> 'yield' backward compatibility issue, not to make the syntax too
> heavyweight. One character is as minimal as we can get.
>
> But now I'm just shoring up the argument based on compatibility. You'll have
> to get Mark or someone else to help you understand their particular argument
> that the function head needs decoration to alert the reader to the possible
> (not required) presence of yield in the body.

Sure, I want :)

> Note also the empty-body basis case -- that's a good argument for function*
> independent from the backward-compatibility and good-for-readers arguments.
>
> /be
>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 2:12 PM
>>
>> I get the point. Indeed. Modes are a kind of magic...
>>
>> Regarding the secondary reason:
>> I don't understand the "difference" well, could you explain in detail?
>> You know, all other languages that are dynamically typed and have
>> generators, such as python, lua, and even JavaScript 1.8 don't
>> distinguish two kinds of the functions.
>> I guess this directly means that there isn't something different as
>> you said (because they all have more or less made successful).
>> And in my personal view, yield is something that can be generalized
>> together with return, like
>>
>> - return: discards the succeeding partial continuation there
>> - yield: preserve the succeeding partial continuation there
>>
>> It is very clear in a sense, I believe. So my guess is that the
>> strangeness yields have is a mater of getting used to, and that it is
>> much more natural to treat two of them as a same thing.
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Mark S. Miller <mailto:[hidden email]>
>> August 31, 2013 1:33 PM
>>
>> On Sat, Aug 31, 2013 at 1:14 PM, Yuichi Nishiwaki
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     OK, right. I understand my first propose does not work. :-|
>>     So one more question is how about making '*' optional in strict mode?
>>     (Should I separate the topic to another?)
>>
>>     2013/9/1 Brendan Eich <[hidden email]
>>     <mailto:[hidden email]>>:
>>
>>     > Let's not go in circles -- the primary reason for function* is
>>     because yield
>>     > is not reserved in JS and is used by web content as a plain
>>     identifier. It
>>     > is a low-precedence unary prefix operator, so cannot be contextually
>>     > reserved by a grammatical restriction as "module" can. It needs
>>     opt-in
>>     > syntax.
>>     >
>>     > Separately, some on TC39 want a flag on the function, in the
>>     head syntax, to
>>     > alert readers to the generator. That's a secondary reason,
>>     independent and
>>     > not as strong in my view.
>>
>>
>> I am one of those on TC39 that want the visible flag. Since, in my view,
>> the only non-mistaken need to preserve sloppy mode is as an ES3
>> compatibility mode and ES3 has no generators, I consider this flagging issue
>> to be the important one. Yes, you have to read the function to know *what*
>> it generates. But even before you've figured that out, your whole effort to
>> read the function is different once you know you're reading a generator
>> function. Better to know it early.
>>
>> Code is read much more than it is written -- at least code that matters.
>>
>>
>>     >
>>     > There's nothing to "get" or "not get" about backward
>>     compatbility. It just
>>     > "is". :-|
>>     >
>>     > /be
>>     >
>>     >> Yuichi Nishiwaki <mailto:[hidden email]
>>     <mailto:[hidden email]>>
>>     >> August 31, 2013 12:55 PM
>>     >>
>>     >> I can't get the point, why you need to know if the function is a
>>     >> generator or not at a glance?
>>     >>
>>     >> 1. Forcing users to mark the function as a generator is only a
>>     >> duplication. It basically doesn't have any meaning other than
>>     >> double-checking, and fundamental risk for the unintentional
>>     creation
>>     >> is still not removed.
>>     >> 2. Even if you know the function is a generator in early, you still
>>     >> need to read the entire source code to get the information
>>     about what
>>     >> the generator yields and when it stops.
>>     >> _______________________________________________
>>     >> es-discuss mailing list
>>     >> [hidden email] <mailto:[hidden email]>
>>     >> https://mail.mozilla.org/listinfo/es-discuss
>>     >>
>>     >> Oliver Hunt <mailto:[hidden email] <mailto:[hidden email]>>
>>
>>     >> August 31, 2013 12:25 PM
>>     >>
>>     >> On Aug 31, 2013, at 12:15 PM, Yuichi
>>     Nishiwaki<[hidden email]
>>     <mailto:[hidden email]>>
>>
>>     >> wrote:
>>     >>
>>     >>> Hi all, I just found a post that the current generator syntax
>>     >>> (function *) seems have decided in:
>>     >>>
>>     >>>
>>     https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>     >>>
>>     >>> According to the post, the biggest reason the star syntax is
>>     adopted
>>     >>> for now is that you cannot write empty generators with star-less
>>     >>> functions in a consistent simple way. But the situation has
>>     changed,
>>     >>> and in the current spec (rev 17) yield* is now capable of
>>     taking any
>>     >>> kind of iterator, so you can make empty generators just like
>>     >>>
>>     >>> ```js
>>     >>> function * () {
>>     >>>     yield * [];
>>     >>> }
>>     >>> ```
>>     >>>
>>     >>> This looks enough good and simple at least to me. And I wonder
>>     if even
>>     >>> now generators still need to be declared with 'star's. What
>>     are the
>>     >>> advantages of 'star'ed generators rather than 'star'-lesses?
>>     If not
>>     >>> exist, shouldn't it be removed (for the simplicity)?
>>     >>>
>>     >>
>>     >> The reason for the * is substantially (IIRC) to make it
>>     possible for an
>>     >> engine
>>     >> to help prevent developers from unintentionally creating a
>>     generator
>>     >> function,
>>     >> and to make it possible for someone attempting to use a function to
>>     >> identify immediately
>>     >> whether it is a generator or a regular function.
>>     >>
>>     >> --Oliver
>>     >>
>>     >>> Thank you.
>>     >>>
>>     >>> --
>>     >>> Yuichi Nishiwaki
>>     >>> _______________________________________________
>>     >>> es-discuss mailing list
>>     >>> [hidden email] <mailto:[hidden email]>
>>
>>     >>> https://mail.mozilla.org/listinfo/es-discuss
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> es-discuss mailing list
>>     >> [hidden email] <mailto:[hidden email]>
>>
>>     >> https://mail.mozilla.org/listinfo/es-discuss
>>     >>
>>     >> Yuichi Nishiwaki <mailto:[hidden email]
>>     <mailto:[hidden email]>>
>>     >> August 31, 2013 12:15 PM
>>     >>
>>     >> Hi all, I just found a post that the current generator syntax
>>     >> (function *) seems have decided in:
>>     >>
>>     >> https://mail.mozilla.org/pipermail/es-discuss/2011-July/015799.html
>>     >>
>>     >> According to the post, the biggest reason the star syntax is
>>     adopted
>>     >> for now is that you cannot write empty generators with star-less
>>     >> functions in a consistent simple way. But the situation has
>>     changed,
>>     >> and in the current spec (rev 17) yield* is now capable of
>>     taking any
>>     >> kind of iterator, so you can make empty generators just like
>>     >>
>>     >> ```js
>>     >> function * () {
>>     >> yield * [];
>>     >> }
>>     >> ```
>>     >>
>>     >> This looks enough good and simple at least to me. And I wonder
>>     if even
>>     >> now generators still need to be declared with 'star's. What are the
>>     >> advantages of 'star'ed generators rather than 'star'-lesses? If not
>>     >> exist, shouldn't it be removed (for the simplicity)?
>>     >>
>>     >> Thank you.
>>     >>
>>     >> --
>>     >> Yuichi Nishiwaki
>>     >> _______________________________________________
>>     >> es-discuss mailing list
>>     >> [hidden email] <mailto:[hidden email]>
>>
>>     >> https://mail.mozilla.org/listinfo/es-discuss
>>     >>
>>     >
>>     _______________________________________________
>>     es-discuss mailing list
>>     [hidden email] <mailto:[hidden email]>
>>
>>     https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 1:14 PM
>>
>> OK, right. I understand my first propose does not work. :-|
>> So one more question is how about making '*' optional in strict mode?
>> (Should I separate the topic to another?)
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Brendan Eich <mailto:[hidden email]>
>> August 31, 2013 12:58 PM
>> Let's not go in circles -- the primary reason for function* is because
>> yield is not reserved in JS and is used by web content as a plain
>> identifier. It is a low-precedence unary prefix operator, so cannot be
>> contextually reserved by a grammatical restriction as "module" can. It needs
>> opt-in syntax.
>>
>> Separately, some on TC39 want a flag on the function, in the head syntax,
>> to alert readers to the generator. That's a secondary reason, independent
>> and not as strong in my view.
>>
>> There's nothing to "get" or "not get" about backward compatbility. It just
>> "is". :-|
>>
>> /be
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> Yuichi Nishiwaki <mailto:[hidden email]>
>> August 31, 2013 12:55 PM
>> I can't get the point, why you need to know if the function is a
>> generator or not at a glance?
>>
>> 1. Forcing users to mark the function as a generator is only a
>> duplication. It basically doesn't have any meaning other than
>> double-checking, and fundamental risk for the unintentional creation
>> is still not removed.
>> 2. Even if you know the function is a generator in early, you still
>> need to read the entire source code to get the information about what
>> the generator yields and when it stops.
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Brian Kardell
In reply to this post by Brendan Eich-3


On Aug 31, 2013 6:20 PM, "Brendan Eich" <[hidden email]> 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).
>
> /be

Yes.  I know its not especially useful and i debated sitting it out (as i often do on this list) - i think #1 stands on it own, but I felt that there was some debate about the value of #3 which isn't for compatibility or even function but for developers, and perhaps it might be useful to say that given the choice between * and none, I'd prefer the visual queue that tells me its different with an easy scan because...It's bikesheddy - i know but I thought it worth saying that as one of those devs I think it has value.  So if we can get 1 and 3 with a single char... Win.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Yuichi Nishiwaki
In reply to this post by Mark S. Miller-2

You say the things get worse because introducing yields causes a probem that another parameter -- when to call a certain code block -- might be added at the time when readung the code, but I don't agree. There is already a parameter for code reading: how many times the code will be executed (or in short, whether the code is run, 0 or 1).

Whenever you read the code you have to read until you come across the first, assumed to be executed when passed the arguments you want do at the time, return statement to know what will happen when you invoke the function, and this is the same case to yields.  You need to take care of the timing only after that.

On Sep 1, 2013 7:48 AM, "Mark S. Miller" <[hidden email]> wrote:
On Sat, Aug 31, 2013 at 2:12 PM, Yuichi Nishiwaki <[hidden email]> wrote:
I get the point. Indeed. Modes are a kind of magic...

Regarding the secondary reason:
I don't understand the "difference" well, could you explain in detail?


  function f(....) {
    // .... code sequence 1

    // .... balanced code sequence 2

    // .... code sequence 3
  }

Without looking at f's parameters, code sequence 1, or code sequence 3, the reader knows that code sequence 2 will execute some number of times, perhaps 0, only during the turn in which f is called and before f returns. Once f's caller gets control again, code sequence 2 will no longer ever execute as part of that call to f.  The only contextual knowledge the reader needs in order to know this is that there are no intermediate function definitions within f wrapping code sequence 2 -- i.e., that code sequence 2 is code of the function f itself, as opposed to code of a function within function a. It suffices to check that there are no unbalanced function definition starts in code sequence 1. Beyond this "is it wrapped in a function" question, the reader doesn't even care if code sequence 1 starts a control structure wrapping code sequence 2, that is closed in code sequence 3.

If the header says |function*|, then the reader knows that they do not know all this, and a more careful read is needed to understand when code sequence 2 might execute as part of a given call to f after f's caller resumes.

See <http://erights.org/data/irrelevance.html> on the need to do partial reasoning about code fragments. I find it frustrating that there so little computer science devoted to the cognitive load required of such partial program understanding tasks. This properly should be part of the study of "notation as user interface".

 
You know, all other languages that are dynamically typed and have
generators, such as python, lua, and even JavaScript 1.8 don't
distinguish two kinds of the functions.
I guess this directly means that there isn't something different as
you said (because they all have more or less made successful).
And in my personal view, yield is something that can be generalized
together with return, like

- return: discards the succeeding partial continuation there
- yield: preserve the succeeding partial continuation there

It is very clear in a sense, I believe. So my guess is that the
strangeness yields have is a mater of getting used to, and that it is
much more natural to treat two of them as a same thing.
--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'function *' is not mandatory

Allen Wirfs-Brock
In reply to this post by Brendan Eich-3

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 GeneratorFunctio
 n by the presences of yield may be fine for compilers but it isn't good enough for human readers or writiers.

Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123