Re: Reserving await within Arrow Functions

Tab Atkins Jr. wrote: On Thu, Dec 12, 2013 at 11:41 PM, Brendan Eich wrote: > John Barton wrote: >> >> offline Mark lured me in to making more suggestions. I bit: >> >> p1>< foo(a,b); // p1 "eventually when the sand runs out" foo(a,b); >> p1<> foo(a,b); // Because a wikipedia page has d

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 11:41 PM, Brendan Eich wrote: > John Barton wrote: >> >> offline Mark lured me in to making more suggestions. I bit: >> >> p1 >< foo(a,b); // p1 "eventually when the sand runs out" foo(a,b); >> p1 <> foo(a,b); // Because a wikipedia page has diamond for temporal logic >> '

Re: Reserving await within Arrow Functions

Grrr, something stripped leading spaces. Trying again. /be - public

Re: Reserving await within Arrow Functions

John Barton wrote: offline Mark lured me in to making more suggestions. I bit: p1 >< foo(a,b); // p1 "eventually when the sand runs out" foo(a,b); p1 <> foo(a,b); // Because a wikipedia page has diamond for temporal logic 'eventually'. I guess angle brackets in general are trouble however, I

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 1:41 PM, Rick Waldron wrote: > > > > On Thu, Dec 12, 2013 at 2:56 PM, John Barton wrote: > >> >> >> >> On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller wrote: >>> >>> Keep in mind that infix ! is proposed < >>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> fo

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 2:56 PM, John Barton wrote: > > > > On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller 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., >> >>

Re: Reserving await within Arrow Functions

> Well, let's use it in context then. I think this is correct? > > ```js > const flattened = iterableReduce(iterableOfIterables, (a, b) =*> { yield* > a; yield* b; }, []); > ``` > Makes sense to me. Still, what's the alternative? function* concat(a, b) { yield* a; yield* b; } const flat

Re: Reserving await within Arrow Functions

1) ... functions "express" mappings 2) Generators "express" sequences 3) Don't muddy the waters If only!-( In current ES6 design, functions are mixed with generators (probably based on the notion that the generator function call is suspended, even though, in reality, generator functions return

RE: Reserving await within Arrow Functions

: Mark S. Miller; Brendan Eich; es-discuss Subject: Re: Reserving await within Arrow Functions ```js const concat = (a, b) =*> { yield* a; yield* b; } ``` Thanks. For this particular example, it's no big deal to use longhand: function* concat(a, b) { yield* a; yield* b; } But you coul

Re: Reserving await within Arrow Functions

> > > ```js > const concat = (a, b) =*> { yield* a; yield* b; } > ``` > Thanks. For this particular example, it's no big deal to use longhand: function* concat(a, b) { yield* a; yield* b; } But you could throw a couple of `this`s in there and drive the argument that way. But are we going t

RE: Reserving await within Arrow Functions

;mailto:erig...@google.com> Cc: Brendan Eich<mailto:bren...@mozilla.com>; es-discuss<mailto:es-discuss@mozilla.org> 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 loc

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 CoffeeScrip

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller 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 __

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 2:46 PM, Brendan Eich 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 parame

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 10:37 AM, Kevin Smith 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 f

Re: Reserving await within Arrow Functions

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

Re: Reserving await within Arrow Functions

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 car

Re: Reserving await within Arrow Functions

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

Re: Reserving await within Arrow Functions

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? N

Re: Reserving await within Arrow Functions

:) 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

Re: Reserving await within Arrow Functions

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

Re: Reserving await within Arrow Functions

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 (

Re: Reserving await within Arrow Functions

> > > =>, *=>, !=> > =>, =*>, =!> > =>, *>, !> > > 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,

RE: Reserving await within Arrow Functions

`Promise`. From: es-discuss on behalf of Mark S. Miller 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 consid

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 functi

Re: Reserving await within Arrow Functions

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

Re: Reserving await within Arrow Functions

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

Re: Reserving await within Arrow Functions

On Thu, Dec 12, 2013 at 9:40 AM, Brendan Eich 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 onl

Re: Reserving await within Arrow Functions

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 wi

Reserving await within Arrow Functions

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

Re: Reserving await within Arrow Functions

Couldn't a slight variation be used for arrow functions, rather than adding yet another character in front or behind it? For example, using -> or ~> (unless they have been reserved for something in ES7): var arrowFunction = (a, b) => a+b; var generator = (a, b) -> yield a; yield b; var async = (a,

Re: Reserving await within Arrow Functions

I always want the * to be mandatory for full generator functions as a visual cue. I suspect I would want something similar for async functions but I can see logic to not needing the same visual cue on an arrow function. Arrow functions would often be significantly shorter, so the visual cue of

Re: Reserving await within Arrow Functions

Why is it always easier to see the errors after hitting that "Send" button, anyway? Simplified and ASI corrected: AsyncFunctionDeclaration: "async" [NoNewLine] BindingIdentifier ... async F() {} AsyncFunctionExpression: "async" [NoNewLine] BindingIdentifier ...

Re: Reserving await within Arrow Functions

> > > To say a bit more, if we don't want 'yield' in the body of an arrow to > imply that that arrow function is a generator function, then the same > argument seems to apply to 'await'. So we need a sigil or equivalent. But > =>! is at least as infeasible as =>*. So perhaps we cannot reserve 'awai

Re: Reserving await within Arrow Functions

Brendan Eich wrote: But to recap the TC39 meeting discussion, we do not believe we can add =>* or =>! -- the latter is arrow with a unary logical negation expression as the body. Other places to put the * and ! are problematic due to ASI. So what exactly are we gonna do for async arrows, if an

Re: Reserving await within Arrow Functions

But to recap the TC39 meeting discussion, we do not believe we can add =>* or =>! -- the latter is arrow with a unary logical negation expression as the body. Other places to put the * and ! are problematic due to ASI. So what exactly are we gonna do for async arrows, if anything? We said no/de

Re: Reserving await within Arrow Functions

On Dec 11, 2013, at 2:44 PM, Mark S. Miller wrote: > Yes. I think the reasons for wanting the "*", whether you agree with them or > not, all apply equally to "!" (or whatever the syntax is). > And if there is a syntactic flag like that, I don't see that we need to worry about preserving anyt

Re: Reserving await within Arrow Functions

On Wed, Dec 11, 2013 at 5:40 PM, Brendan Eich wrote: > Rick Waldron wrote: > >> On Wed, Dec 11, 2013 at 5:31 PM, Brendan Eich > bren...@mozilla.com>> wrote: >> >> Thanks for bringing this up -- it's a good point. Unlike ES5 >> >> strict and 'yield', the cat is not yet out of the bag. We n

Re: Reserving await within Arrow Functions

Yes. I think the reasons for wanting the "*", whether you agree with them or not, all apply equally to "!" (or whatever the syntax is). On Wed, Dec 11, 2013 at 2:41 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I think this largely comes down to whether people think an "async" > s

RE: Reserving await within Arrow Functions

I think this largely comes down to whether people think an "async" signifier (whether `async`, `^`, or `!`) is a good notification to have  that you are about to enter async code. I remember from a few weeks back we had (yet another) thread on generators-without-the-star, and a few people were

Re: Reserving await within Arrow Functions

Rick Waldron wrote: On Wed, Dec 11, 2013 at 5:31 PM, Brendan Eich > wrote: Thanks for bringing this up -- it's a good point. Unlike ES5 strict and 'yield', the cat is not yet out of the bag. We need to commit, though. I suspect there are a few keywords t

Re: Reserving await within Arrow Functions

On Wed, Dec 11, 2013 at 5:31 PM, Brendan Eich wrote: > Thanks for brining this up -- it's a good point. Unlike ES5 strict and > 'yield', the cat is not yet out of the bag. We need to commit, though. > I suspect there are a few keywords to reserve within new syntactic forms, ie. ClassBody and Mod

Re: Reserving await within Arrow Functions

Thanks for brining this up -- it's a good point. Unlike ES5 strict and 'yield', the cat is not yet out of the bag. We need to commit, though. /be Kevin Smith December 11, 2013 1:00 PM I think we should at least consider for a moment reserving `await` within the b

Reserving await within Arrow Functions

I think we should at least consider for a moment reserving `await` within the body of arrow functions. Consider the following event handling scenario, where lexical `this` is an important feature: this.button.on("click", $=> { this.getDataAsync().then(data => { this.showDa