Kevin Smith wrote:
My thoughts:
Again, generators are not a good fit for arrows - generators define
sequences, not mappings.
Yep.
Secondly, we should be conservative in our usage of arrow-like
operators - we only have so many decent looking things left!
What's more, ~ has nothing to do with generators, which use *
(function*, yield*). Incoherent grawlix is no-go.
Third, looking at your third case (and removing unnecessary parens):
var async = (a, b) ~> await a + await b;
It's completely obvious to the reader (by virtue of the await
expressions) that we are looking at an async function. Having a
different operator here offers neither the reader nor the parser any
real help. It just makes the language more grawlixy and less DWIM.
The issue with 'await' is: apart from sequence vs. mapping, given that
arrows have a limited Tennent's Correspondence Principle for not only
|this| and |super|, is it confusing to have |arguments|, |yield|, and
|await| not mean outer "bindings", vs. inner?
This line of reasoning only applies to async arrows, and not to async
function declarations, expressions, or methods. Again, arrows are by
nature syntax-light and tolerate a higher degree of "inference" than
other forms.
My point is that we should reserve "await" within arrows to preserve
these design options down the road. It can always be unreserved later.
I think you have a point, whether we make |await| work or ban it to
avoid partial-TCP confusion.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
