Re: Proposal: Generator returning a value should throw SyntaxError

[Brendan Eich]

David Herman wrote:

Finally, task.js is just an example of building a control abstraction out of 
iterators. It happens that the for-of control flow form is imperative and 
doesn't have a use for a return value. That doesn't mean other control flow 
operations won't.


+1. The need for an affordance for some use-cases and lack of need for 
others does not undermine the affordance's value.


PEP-380 is worth a read, IMHO, for anyone who values Python's 
experience. You have to grok some history and custom jargon.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[David Herman]

Here are several ways to think about return:

- A generator function is like a normal function but it can be paused. The act 
of pausing can send an intermediate value out to the caller (yield's argument) 
and the caller can send an intermediate value back in when resuming (yield's 
result). None of this changes the fact that, like ordinary functions, there are 
still arguments passed into the function and a result passed out. Refusing 
return values just breaks down this generalization.

- A generator function produces an iterator object, which produces a record on 
each iteration that has a .value and a .done flag indicating whether the 
iteration is done. Refusing return values eliminates the .value field in this 
special case, making things less consistent.

Finally, task.js is just an example of building a control abstraction out of 
iterators. It happens that the for-of control flow form is imperative and 
doesn't have a use for a return value. That doesn't mean other control flow 
operations won't.

Dave

On Jan 27, 2014, at 2:18 PM, Adam Ahmed  wrote:

> In light of the recent thread discussing async and await keywords, I thought 
> it'd be appropriate to raise this point again, understanding it may be too 
> late to make a change.
> 
> As my original post details, the concept of `return` within a generator is 
> surprising in its difference in behavior from `yield`.
> 
> This does not do as 'expected' in a for-in:
> 
> function * threeCount() {
>   yield 1;
>   yield 2;
>   return 3;
> }
> 
> The argument for allowing return values was that usages in the vein of 
> task.js will use the return value as a real return value and the yields for 
> scheduling.
> 
> If we' re going to have async and await serve the scheduling purpose as well, 
> can we remove the 'return' foot gun from generators? It sounds like it's just 
> a stopgap until async-await, and a painful one, IMO. A syntax error on a 
> generator that returns values would make the scheduling (async-await) vs 
> iteration (generator) use cases much more clear. It'll be much easier for new 
> JS devs to understand generators.
> 
> Happy to be shutdown again, just thought it was worth reconsidering with new 
> async-await keywords in play.
> 
> On 27/09/2013 3:46 PM, "Brandon Benvie"  wrote:
> On 9/26/2013 10:40 PM, Brandon Benvie wrote:
> ```js
> function* foo() {
>   yield 'what';
>   yield 'ever';
>   return "DONE";
> }
> 
> function* bar() {
>   console.log(yield* foo());
> }
> ```
> 
> Err, this logs "DONE" when you do:
> 
> ```js
> var gen = bar();
> gen.next();
> gen.next();
> gen.next();
> ```
> but you got the idea...
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[Adam Ahmed]

In light of the recent thread discussing async and await keywords, I
thought it'd be appropriate to raise this point again, understanding it may
be too late to make a change.

As my original post details, the concept of `return` within a generator is
surprising in its difference in behavior from `yield`.

This does not do as 'expected' in a for-in:

function * threeCount() {
  yield 1;
  yield 2;
  return 3;
}

The argument for allowing return values was that usages in the vein of
task.js will use the return value as a real return value and the yields for
scheduling.

If we' re going to have async and await serve the scheduling purpose as
well, can we remove the 'return' foot gun from generators? It sounds like
it's just a stopgap until async-await, and a painful one, IMO. A syntax
error on a generator that returns values would make the scheduling
(async-await) vs iteration (generator) use cases much more clear. It'll be
much easier for new JS devs to understand generators.

Happy to be shutdown again, just thought it was worth reconsidering with
new async-await keywords in play.
On 27/09/2013 3:46 PM, "Brandon Benvie"  wrote:

> On 9/26/2013 10:40 PM, Brandon Benvie wrote:
>
>> ```js
>> function* foo() {
>>   yield 'what';
>>   yield 'ever';
>>   return "DONE";
>> }
>>
>> function* bar() {
>>   console.log(yield* foo());
>> }
>> ```
>>
>
> Err, this logs "DONE" when you do:
>
> ```js
> var gen = bar();
> gen.next();
> gen.next();
> gen.next();
> ```
> but you got the idea...
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[Brandon Benvie]

On 9/26/2013 10:40 PM, Brandon Benvie wrote:

```js
function* foo() {
  yield 'what';
  yield 'ever';
  return "DONE";
}

function* bar() {
  console.log(yield* foo());
}
```


Err, this logs "DONE" when you do:

```js
var gen = bar();
gen.next();
gen.next();
gen.next();
```
but you got the idea...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[Brandon Benvie]

On 9/26/2013 7:18 PM, Adam Ahmed wrote:
Thanks, I see. The usage is for TaskResult sorts of things where the 
scheduling is done via calls to `yield`, and the output of the 
function is done via `return`. Fair enough. It still seems like a huge 
footgun for the other cases which I'd expect are far more common than 
cooperative scheduling, but I can respect that decision.


An example use case is delegating yield:

```js
function* foo() {
  yield 'what';
  yield 'ever';
  return "DONE";
}

function* bar() {
  console.log(yield* foo());
}
```

This console.logs "DONE". Can't do this without a way to handle a return 
value from generators.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[Adam Ahmed]

Thanks, I see. The usage is for TaskResult sorts of things where the
scheduling is done via calls to `yield`, and the output of the function is
done via `return`. Fair enough. It still seems like a huge footgun for the
other cases which I'd expect are far more common than cooperative
scheduling, but I can respect that decision.

Cheers!


On 27 September 2013 12:00, Brendan Eich  wrote:

> Sorry, premature send!
>
>> Brendan Eich 
>> September 26, 2013 6:57 PM
>>
>> We deliberated long and hard, after going through a design state without
>> return expr;, on this. We agree with
>>
>> http://www.python.org/dev/**peps/pep-0380/
>>
>
> We want return expr; -- not for the 'for-of' special forms, which clients
> use knowingly to consume in-band values, not the OOB return value -- but
> for the case of generators used as tasks (see ), where the scheduler can
> make good use of the return value:
>
> https://github.com/mozilla/**task.js 
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[Brendan Eich]

Sorry, premature send!

Brendan Eich 
September 26, 2013 6:57 PM
We deliberated long and hard, after going through a design state 
without return expr;, on this. We agree with


http://www.python.org/dev/peps/pep-0380/


We want return expr; -- not for the 'for-of' special forms, which 
clients use knowingly to consume in-band values, not the OOB return 
value -- but for the case of generators used as tasks (see ), where the 
scheduler can make good use of the return value:


https://github.com/mozilla/task.js

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Generator returning a value should throw SyntaxError

[Brendan Eich]

We deliberated long and hard, after going through a design state without 
return expr;, on this. We agree with


http://www.python.org/dev/peps/pep-0380/

Adam Ahmed wrote:

Hi all,

Long-time lurker, first-time poster. Profuse apologies if this was 
mentioned before and I failed to find it.


I've been using V8's generator implementation in Node 0.11.x recently, 
and have come across what I believe is a footgun with generators 
currently. That is - the ability to return a value, not just yield a 
value. I am proposing that while `return;` is still allowed, `return 
value;` becomes a syntax error within generators.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Generator returning a value should throw SyntaxError

[Adam Ahmed]

Hi all,

Long-time lurker, first-time poster. Profuse apologies if this was
mentioned before and I failed to find it.

I've been using V8's generator implementation in Node 0.11.x recently, and
have come across what I believe is a footgun with generators currently.
That is - the ability to return a value, not just yield a value. I am
proposing that while `return;` is still allowed, `return value;` becomes a
syntax error within generators.

An alternative proposal is to implicitly treat `return value` within a
generator as `yield value; return;`, however this would create a difference
in the semantics between `return;` and `return undefined;` that currently
doesn't exist and I believe such a thing has been proposed before
unsuccessfully in http://esdiscuss.org/topic/void-as-a-value

There are a couple reasons I believe this should be a syntax error.

Firstly, for-of doesn't support it, thereby making it a bit halfway-there
to start with:

function * upToThree() {
yield 1;
yield 2;
return 3;
}

for(var num of upToThree()) {
console.log(num); // 1, then 2. Never logs 3
}

It also makes it impossible to return an empty iteration (or at least,
impossible to distinguish an empty iteration from an iterator that has a
single undefined value):

function* empty() {
return; // or is it
// return undefined; ?
}

Supporting that style also has knock-on effects for consuming generators
like takeUntil (which will execute a function on each value, and yield them
until it reaches one where the function returns true). Functions like this
will have to precompute the _next_ value to see if they should yield or
return the current value. For example:

function * takeUntilThree(iterator) {
var curr, next;
next = iterator.next();
while(!next.done) {
curr = next;
next = iterator.next();
if (next === 3) { // only know which to do based on the _next_
value)
return curr.value;
} else {
yield curr.value;
}
}
return curr && curr.value; // Note: the undefined vs empty problem
is still not fixed.
}

var untilThree = takeUntilThree(upToThree());
untilThree.next(); // { value : 1, done : false }
untilThree.next(); // { value : 2, done : true }

For these reasons, I find the ability to return a value from a generator is
not useful (though I may have missed a use case).

Given that any generator with an occurrence of `return value;` can be
reimplemented cleanly as

yield value;
return;

I suspect we can remove the footgun by throwing early when an attempt to
return a value is encountered within a generator.

I must admit I'm not across how difficult this would be for implementers.
But I believe it will remove potential danger for developers without
harming any real usages.

Thanks for listening! Apologies for length!

Adam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss