On Thu, Dec 12, 2013 at 9:40 AM, Brendan Eich <[email protected]> wrote:
> 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? No. > 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. > I'll continue to point out that the confusion is largely a product of language lawyering, not real-world expectations of JS behavior. Banning await here is only a solution if you're also not going to ban an async descriptor on the arrow expression. THAT is the mistake.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
