Subject: Re: Harmony - proxies | asynchronous

[Dean Landolt]

On Tue, Sep 6, 2011 at 2:37 PM, Brendan Eich <brendan at mozilla.com> 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!
>

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