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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
