<br><br><div class="gmail_quote">On Tue, Sep 6, 2011 at 2:37 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><div>On Sep 6, 2011, at 9:47 AM, Dean Landolt wrote:</div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>We considered that, but generator is not reserved, and reserving it in ES6 requires newline sensitivity at least. Consider an anonymous generator similar to the one you typed:</div>
<div><br></div><div>  generator()</div><div>  {...}</div><div><br></div><div>where ... is actual code (and the {...} style may use multiple lines and indentation). This could be valid code in the field today, relyling on ASI to insert the semicolon after "generator()".</div>
</div></blockquote></div></blockquote><div><br></div></div>Hold this thought.</div><div><br></div><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>What's more, the precedent in Python is not a negative or a trivial benefit. Besides reusing brain-print, we stand on field-tested design in a similar language. Python uses def for both functions and generators.</div>

</div></blockquote><div><br></div><div><br></div><div>But isn't this just a design flaw in python (and js 1.7) -- remedied, no less, by your disambiguating asterisk? Personally I'm fond of the asterisk, and the symmetry of function* and yield*, but this is a distinct grammatical construct from function, right?</div>
</div></blockquote><div><br></div></div>No. That's another point: we do not massively duplicate the grammar so as to rule out yield in function syntactically, and require it in function* (indeed it is not requried -- 0 iteration basis case).</div>
<div><br></div><div>Likewise, ES1-5 do not try to restrict return, break, and continue to contexts where they are legal using grammar only. Instead, the poor-man's operational semantic steps and model, and some prose, combine to do the deeds.</div>
<div><br></div><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div> This argument doesn't strike me as very winful against any other (syntactically safe) spelling.</div></div></blockquote><div>
<br></div></div>It's the "What's more" argument, on top of the "Hold this thought" main point. </div></div></blockquote><div><br></div><div><br></div><div>I didn't see this line of reasoning -- I thought your main point was that `generator` was grammatically ambiguous. My apologies if this was so obvious as to be implied, but in any event, it was a trivial little nit begging for a stronger rationale, which was delivered and then some.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>Both matter, though. Generator functions are still functions of a kind. So are constructors (which in the current classes proposal are grammatically distinct).</div>
<div><br></div><div>As in Python, which is valuable precedent for those who know it and those who've studied its rationale docs (PEPs), the commonality among function variants is greater than the differences that might lead us on a snipe-hunt for an unreserved keyword to use.</div>
<div><br></div><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote">
<div>What it's really lacking is a version with * syntax of harmony generators, which fixes the locality of reference problems</div></div></blockquote><div><br></div></div><div>"locality of reference" sounds cool, but what do you mean? It suggests some "spooky action at a distance" but there's no such runtime QM-like problem.</div>
<div><br></div><div>If you mean that decorating the head of the generator syntax to telegraph that yield may (not must) occur later is valuable, I agree. </div></div></div></blockquote><div><br></div><div><br></div><div>Yes, I was referring to those sneaky, hidden preemption points where variables change out from under you. This is helped by the * head, but IMHO the deeper problem with libraries like node-fibers that Mikeal was griping about is rooted in a dynamic `wait` call -- preemption that could aliased or buried deep in a call stack. AFAICT generators completely prevent this -- preemption cannot happen without an explicit, static `yield` prefix right at the call site. This is really where "spooky action at a distance" shows up, and to be fair, python and js 1.6 generators are already immune to it.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div>But there's no "physics" at work here. A human reader may miss the yield (if there is a yield -- if not, then the * is valuable to make an empty generator, something not possible in Python AFAIK).</div>
</div></div></blockquote><div><br></div><div><br></div><div>Yes, a human reader could miss yield -- easier than one could miss a nested callback function (barring the acceptance of block lambda) -- but it cannot, under any circumstances, be hidden from view. Unlike a `wait` function.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div>Likewise, a human reader may miss the * in the head *and* miss the one or more yields in an interesting generator function.</div>
<div><br></div><div>Readers may miss all sorts of key *static* dependencies among parts of a larger function or unit of code. There are no silver bullets here.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div> and makes it more clear when you're working with a task. Any word on when they're intended to land in spidermonkey? I see Dave Herman filed a bug back in June but there's no status on it.</div>
</div></blockquote><br></div></div><div>I will stir the pot!</div></div></blockquote><div><br></div><div>Thanks!</div></div>