Subject: Re: Harmony - proxies | asynchronous

Dean Landolt dean at
Tue Sep 6 13:07:37 PDT 2011

On Tue, Sep 6, 2011 at 2:37 PM, Brendan Eich <brendan at> wrote:

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

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.

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.

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.

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

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.

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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list