Subject: Re: Harmony - proxies | asynchronous

[Brendan Eich]

On Sep 6, 2011, at 9:47 AM, Dean Landolt wrote:

> 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:
> 
>   generator()
>   {...}
> 
> 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()".

Hold this thought.


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

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

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.


> This argument doesn't strike me as very winful against any other (syntactically safe) spelling.

It's the "What's more" argument, on top of the "Hold this thought" main point. Both matter, though. Generator functions are still functions of a kind. So are constructors (which in the current classes proposal are grammatically distinct).

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.


> What it's really lacking is a version with * syntax of harmony generators, which fixes the locality of reference problems

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

If you mean that decorating the head of the generator syntax to telegraph that yield may (not must) occur later is valuable, I agree. 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). Likewise, a human reader may miss the * in the head *and* miss the one or more yields in an interesting generator function.

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.


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

I will stir the pot!

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110906/74afd16e/attachment.html>