Reserving await within Arrow Functions

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Reserving await within Arrow Functions

Kevin Smith

    var arrowFunction = (a, b) => a+b; 
    var generator = (a, b) -> yield a; yield b; 
    var async = (a, b) ~> (await a) + (await b);

My thoughts:

Again, generators are not a good fit for arrows - generators define sequences, not mappings.

Secondly, we should be conservative in our usage of arrow-like operators - we only have so many decent looking things left!

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.

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.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Brendan Eich-3
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Alex Russell-4



On Thu, Dec 12, 2013 at 9:40 AM, Brendan Eich <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Kevin Smith
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.

Not sure I follow - can you elaborate?  What is an "async descriptor on the arrow expression"?


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Alex Russell-4
If you can't indicate that the arrow itself is async somehow (either by prefixing it with "deferred" or "async" or using a variant of the arrow itself, e.g. "~=>"), then you get into the issue Brendan describes when you allow "await" inside the body.


On Thu, Dec 12, 2013 at 10:07 AM, Kevin Smith <[hidden email]> wrote:
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.

Not sure I follow - can you elaborate?  What is an "async descriptor on the arrow expression"?



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Mark S. Miller-2
Putting aside my immediate esthetic reaction, I suggest we consider one of

    =>, *=>, !=>
    =>, =*>, =!>
    =>, *>, !>

Which do you hate least?

Btw, Kevin, I have read and do not understand your argument about why we would not want generator arrow functions but would want async arrow functions. If we could agree on syntax, I still want both.




On Thu, Dec 12, 2013 at 10:11 AM, Alex Russell <[hidden email]> wrote:
If you can't indicate that the arrow itself is async somehow (either by prefixing it with "deferred" or "async" or using a variant of the arrow itself, e.g. "~=>"), then you get into the issue Brendan describes when you allow "await" inside the body.


On Thu, Dec 12, 2013 at 10:07 AM, Kevin Smith <[hidden email]> wrote:
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.

Not sure I follow - can you elaborate?  What is an "async descriptor on the arrow expression"?



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Reserving await within Arrow Functions

Domenic Denicola-2
I agree that there is no difference between generator-returning arrows and promise-returning arrows. Using the earlier type-ish notation, where `=>` is a mapping to `T`,  `=*>` would be a mapping to `Generator<T>`, just like `=!>` would be a mapping to `Promise<T>`.



From: es-discuss <[hidden email]> on behalf of Mark S. Miller <[hidden email]>
Sent: Thursday, December 12, 2013 13:17
To: Alex Russell
Cc: Kevin Smith; Brendan Eich; es-discuss
Subject: Re: Reserving await within Arrow Functions
 
Putting aside my immediate esthetic reaction, I suggest we consider one of

    =>, *=>, !=>
    =>, =*>, =!>
    =>, *>, !>

Which do you hate least?

Btw, Kevin, I have read and do not understand your argument about why we would not want generator arrow functions but would want async arrow functions. If we could agree on syntax, I still want both.




On Thu, Dec 12, 2013 at 10:11 AM, Alex Russell <[hidden email]> wrote:
If you can't indicate that the arrow itself is async somehow (either by prefixing it with "deferred" or "async" or using a variant of the arrow itself, e.g. "~=>"), then you get into the issue Brendan describes when you allow "await" inside the body.


On Thu, Dec 12, 2013 at 10:07 AM, Kevin Smith <[hidden email]> wrote:
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.

Not sure I follow - can you elaborate?  What is an "async descriptor on the arrow expression"?



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Kevin Smith
In reply to this post by Mark S. Miller-2

    =>, *=>, !=>
    =>, =*>, =!>
    =>, *>, !>

Which do you hate least?

Hate is such a strong world...  : )

My aesthetic judgement is that "!" is not a good choice because grawl is bad for beginners.  And async functions will touch beginners quite heavily (I predict).
 

Btw, Kevin, I have read and do not understand your argument about why we would not want generator arrow functions but would want async arrow functions. If we could agree on syntax, I still want both.


Let me restate first.

At a conceptual level, arrows are mappings.  "x goes to whatever".  That is the niche they fill.  That's why they are so beautifully suited to, for example, array iteration functions, promise callbacks, and even event listeners (which can be considered mappings to void).

Async arrows fit right into that niche, except asynchronously.  "x goes to Promise<whatever>".  They will be well-suited to event listeners, in particular.  (See my OP for an example.)

Generators, on the other hand, are a way of implementing a sequence.  As such, they don't fit into that "arrow" niche.

But aren't async functions going to be implemented with generators, basically?  Well, yes, but that's just an implementation detail.  Generators will probably be used to implement async functions, but they are completely different at a conceptual level.

I believe that once we have async functions (and async arrows), the need for a lightweight generator syntax will largely evaporate.

Or to put the question on more utilitarian ground:  given async functions and async arrows, what use cases are left for generator arrows?






_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Jeremy Martin
My apologies if this has already been covered, but can anyone point to the rationale for arrow functions (primarily) targeting mappings?

I think it's fairly self-evident that they are a natural fit for such use cases, but I find it less self-evident that they are inherently not useful for others (e.g., generators). I feel like I keep seeing the following (implied) argument:

1) Arrow functions are good for mappings
2) Generators aren't mappings
3) Arrow functions aren't good for generators.

Grammar problems aside, I guess I don't follow the reasoning to #3.  Conversely, I think that a case could be made that minimizing the differences between "normal" functions and arrow functions is desirable in its own right.



On Thu, Dec 12, 2013 at 1:37 PM, Kevin Smith <[hidden email]> wrote:

    =>, *=>, !=>
    =>, =*>, =!>
    =>, *>, !>

Which do you hate least?

Hate is such a strong world...  : )

My aesthetic judgement is that "!" is not a good choice because grawl is bad for beginners.  And async functions will touch beginners quite heavily (I predict).
 

Btw, Kevin, I have read and do not understand your argument about why we would not want generator arrow functions but would want async arrow functions. If we could agree on syntax, I still want both.


Let me restate first.

At a conceptual level, arrows are mappings.  "x goes to whatever".  That is the niche they fill.  That's why they are so beautifully suited to, for example, array iteration functions, promise callbacks, and even event listeners (which can be considered mappings to void).

Async arrows fit right into that niche, except asynchronously.  "x goes to Promise<whatever>".  They will be well-suited to event listeners, in particular.  (See my OP for an example.)

Generators, on the other hand, are a way of implementing a sequence.  As such, they don't fit into that "arrow" niche.

But aren't async functions going to be implemented with generators, basically?  Well, yes, but that's just an implementation detail.  Generators will probably be used to implement async functions, but they are completely different at a conceptual level.

I believe that once we have async functions (and async arrows), the need for a lightweight generator syntax will largely evaporate.

Or to put the question on more utilitarian ground:  given async functions and async arrows, what use cases are left for generator arrows?






_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
661.312.3853
@jmar777

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Kevin Smith

I think it's fairly self-evident that they are a natural fit for such use cases, but I find it less self-evident that they are inherently not useful for others (e.g., generators). I feel like I keep seeing the following (implied) argument:

1) Arrow functions are good for mappings
2) Generators aren't mappings
3) Arrow functions aren't good for generators.


That would be me.  : )

I'm trying to look at things not just in terms of "what would be useful", although that's important.  I'm looking at the overall design of the language, and understand the way all the parts fit together into a beautiful whole.

It's an aesthetic thing, which I can appreciate may be a little difficult to swallow.

FWIW, I would restate the argument as follows:

1) Arrow functions "express" mappings
2) Generators "express" sequences
3) Don't muddy the waters

Anyway, I'm not really trying to convince anyone.  I just think we should reserve the right to have this discussion later, and not prematurely commit to "=!>" or whatever.



 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Jeremy Martin
:)

Thanks for clarifying.  I guess the part that I'm still questioning, though, is:

1) Arrow functions "express" mappings

This is of course true, but is that not a bit exclusive? They're also great at:

1) Non-mapping iteration (e.g., `forEach()`)
2) Lightweight callbacks
3) Killing off 90% of `var self = this` occurrences.
4) ... not going to continue, speaking to the choir here.

If there are grammar or aesthetic issues involved, I can (ahem) yield on that... but I'm struggling with the *conceptual* discriminating between what arrow functions are or aren't for.


On Thu, Dec 12, 2013 at 2:25 PM, Kevin Smith <[hidden email]> wrote:

I think it's fairly self-evident that they are a natural fit for such use cases, but I find it less self-evident that they are inherently not useful for others (e.g., generators). I feel like I keep seeing the following (implied) argument:

1) Arrow functions are good for mappings
2) Generators aren't mappings
3) Arrow functions aren't good for generators.


That would be me.  : )

I'm trying to look at things not just in terms of "what would be useful", although that's important.  I'm looking at the overall design of the language, and understand the way all the parts fit together into a beautiful whole.

It's an aesthetic thing, which I can appreciate may be a little difficult to swallow.

FWIW, I would restate the argument as follows:

1) Arrow functions "express" mappings
2) Generators "express" sequences
3) Don't muddy the waters

Anyway, I'm not really trying to convince anyone.  I just think we should reserve the right to have this discussion later, and not prematurely commit to "=!>" or whatever.



 



--
Jeremy Martin
661.312.3853
@jmar777

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Brendan Eich-3
In reply to this post by Alex Russell-4
Alex Russell wrote:
>
>     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.

So "No" to all? You want |arguments| and |yield| in arrow functions
working on the immediately enclosing arrow?

Whatever the |await| answer, we need a systematic approach or rule of
thumb for the other forms.

>         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.

Lawyer Alex, esq, could you please answer the question of what
|arguments| in an arrow should do? |yield| in an arrow?

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Kevin Smith
In reply to this post by Jeremy Martin

1) Non-mapping iteration (e.g., `forEach()`)
2) Lightweight callbacks

Or, mappings to void.
 
3) Killing off 90% of `var self = this` occurrences.

Here's is the iffy part.  While getting rid of explicit this-binding is definitely a good thing, we want to make sure that goal fits in with the design at large.

And, previously I meant to say that I'm *trying to understand* the way the language fits together.  Not that I actually *do* understand.  I'll be lucky if I can understand what my two-year old is screaming at me later tonight, let alone a complex evolving language.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Brendan Eich-3
In reply to this post by Mark S. Miller-2
Mark S. Miller wrote:
> Putting aside my immediate esthetic reaction, I suggest we consider
> one of
>
>     =>, *=>, !=>

We went over these at the last TC39 meeting. The *=> and !=> forms are
future-hostile to elided empty parameter list for arrow.

>     =>, =*>, =!>

We didn't consider these carefully, just kind of threw up in our mouths
a little. Probably we should consider again.

>     =>, *>, !>

Losing the = hurts, and starts getting too line-noisy.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Brendan Eich-3
In reply to this post by Kevin Smith
Kevin Smith wrote:
>
>
>     1) Non-mapping iteration (e.g., `forEach()`)
>     2) Lightweight callbacks
>
>
> Or, mappings to void.

Good point -- forEach is an explicit and more efficient map with garbage
result full of undefineds.

>     3) Killing off 90% of `var self = this` occurrences.
>
>
> Here's is the iffy part.  While getting rid of explicit this-binding
> is definitely a good thing, we want to make sure that goal fits in
> with the design at large.

Your quantitative study helped here.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Mark S. Miller-2
In reply to this post by Kevin Smith
On Thu, Dec 12, 2013 at 10:37 AM, Kevin Smith <[hidden email]> wrote:

    =>, *=>, !=>
    =>, =*>, =!>
    =>, *>, !>

Which do you hate least?

Hate is such a strong world...  : )

My aesthetic judgement is that "!" is not a good choice because grawl is bad for beginners.  And async functions will touch beginners quite heavily (I predict).

Keep in mind that infix ! is proposed <http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> for use in ES7 to mean "do this operation eventually", e.g.,

    p2 = p1 ! foo(a, b);

would be equivalent to

    p2 = Promise.cast(p1).send("foo", a, b);

which, for local promises, is equivalent to the ES6

    p2 = Promise.cast(p1).then(r => r.foo(a, b));

The use of infix ! here is based on its similar use for concurrent or async message sending in many process algebra languages as well as Erlang and Scala. This proposal is far from accepted, and not relevant prior to ES7. But given that we do adopt infix ! for mean "do this asynchronously/eventually", it would unduly increase the grawlixness to adopt an unrelated symbol, such as ~>, for async arrows.

 
 

Btw, Kevin, I have read and do not understand your argument about why we would not want generator arrow functions but would want async arrow functions. If we could agree on syntax, I still want both.


Let me restate first.

At a conceptual level, arrows are mappings.  "x goes to whatever".  That is the niche they fill.  That's why they are so beautifully suited to, for example, array iteration functions, promise callbacks, and even event listeners (which can be considered mappings to void).

Async arrows fit right into that niche, except asynchronously.  "x goes to Promise<whatever>".  They will be well-suited to event listeners, in particular.  (See my OP for an example.)

Generators, on the other hand, are a way of implementing a sequence.  As such, they don't fit into that "arrow" niche.

Actually, they do. Thanks to Domenic for triggering the following thought:

Where
    x => t
implements the mapping type X -> T, the corresponding
    x =*> t
implements the mapping type X -> T*, where the "*" here reads like the kleene (or regexp) *, i.e., this function maps from an X to zero or more Ts.

 

But aren't async functions going to be implemented with generators, basically?  Well, yes, but that's just an implementation detail.  Generators will probably be used to implement async functions, but they are completely different at a conceptual level.

I believe that once we have async functions (and async arrows), the need for a lightweight generator syntax will largely evaporate.

Or to put the question on more utilitarian ground:  given async functions and async arrows, what use cases are left for generator arrows?

Concise synchronous generators. 

--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Mark S. Miller-2
In reply to this post by Brendan Eich-3
On Thu, Dec 12, 2013 at 2:46 PM, Brendan Eich <[hidden email]> wrote:
Mark S. Miller wrote:
Putting aside my immediate esthetic reaction, I suggest we consider one of

    =>, *=>, !=>

We went over these at the last TC39 meeting. The *=> and !=> forms are future-hostile to elided empty parameter list for arrow.

You're right. I forgot that problem. OTOH, none of this will happen prior to ES7, and by then we might decide to give up on eliding the empty parens. In any case, my other two suggestions stand. I don't like the look either, but they may be worth it for the brevity for an expected-to-be-common case.

 


    =>, =*>, =!>

We didn't consider these carefully, just kind of threw up in our mouths a little. Probably we should consider again.


    =>, *>, !>

Losing the = hurts, and starts getting too line-noisy.

/be



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

John Barton
In reply to this post by Mark S. Miller-2



On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller <[hidden email]> wrote:
Keep in mind that infix ! is proposed <http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> for use in ES7 to mean "do this operation eventually", e.g.,

    p2 = p1 ! foo(a, b);
 
Please do not do this ;-)
jjb 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Reserving await within Arrow Functions

Kevin Smith
In reply to this post by Mark S. Miller-2

    p2 = p1 ! foo(a, b);

would be equivalent to

    p2 = Promise.cast(p1).send("foo", a, b);

which, for local promises, is equivalent to the ES6

    p2 = Promise.cast(p1).then(r => r.foo(a, b));

Yes, but "!" isn't agreed upon.  By that time, we might be over our CoffeeScript-inspiration long enough to consider thin arrows.  After all, thin arrows are used for a different kind of indirection in C.  Maybe...


Actually, they do. Thanks to Domenic for triggering the following thought:

Where
    x => t
implements the mapping type X -> T, the corresponding
    x =*> t
implements the mapping type X -> T*, where the "*" here reads like the kleene (or regexp) *, i.e., this function maps from an X to zero or more Ts.


Exactly.  That's my point, essentially.  The design niche for arrows is expressing simple surjections (with side-effects of course), not one-to-many relationships.


Concise synchronous generators. 


Restating the feature isn't exactly demonstrating a use case : )  Is there a concrete example which would give us some idea of the benefit of arrow generators?  

It's difficult because we don't have much data yet.  But that lack of data is another argument for reserving await, I think.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Reserving await within Arrow Functions

Domenic Denicola-2
I believe this would be a reasonable concise synchronous generator someone could write:

```js
const concat = (a, b) =*> { yield* a; yield* b; }
```

From: [hidden email]
Sent: ‎12/‎12/‎2013 15:17
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: Reserving await within Arrow Functions


    p2 = p1 ! foo(a, b);

would be equivalent to

    p2 = Promise.cast(p1).send("foo", a, b);

which, for local promises, is equivalent to the ES6

    p2 = Promise.cast(p1).then(r => r.foo(a, b));

Yes, but "!" isn't agreed upon.  By that time, we might be over our CoffeeScript-inspiration long enough to consider thin arrows.  After all, thin arrows are used for a different kind of indirection in C.  Maybe...


Actually, they do. Thanks to Domenic for triggering the following thought:

Where
    x => t
implements the mapping type X -> T, the corresponding
    x =*> t
implements the mapping type X -> T*, where the "*" here reads like the kleene (or regexp) *, i.e., this function maps from an X to zero or more Ts.


Exactly.  That's my point, essentially.  The design niche for arrows is expressing simple surjections (with side-effects of course), not one-to-many relationships.


Concise synchronous generators. 


Restating the feature isn't exactly demonstrating a use case : )  Is there a concrete example which would give us some idea of the benefit of arrow generators?  

It's difficult because we don't have much data yet.  But that lack of data is another argument for reserving await, I think.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12