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

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.