github at esdiscuss.org (2013-07-12T02:27:38.033Z)
Why not use the ! marker both for function declarations and function calls
then:
```js
function! foo(a, b) { }
var v = foo!(a, b);
```
Of, for better symmetry:
```js
function foo!(a, b) { }
var v = foo!(a, b);
```
When you have a lot of code sitting on top of async APIs, you end up with
a high proportion of async calls. So a discreet marker is better than a
heavy keyword like await.
Why not use the ! marker both for function declarations and function calls then: function! foo(a, b) { } var v = foo!(a, b); Of, for better symmetry: function foo!(a, b) { } var v = foo!(a, b); When you have a lot of code sitting on top of async APIs, you end up with a high proportion of async calls. So a discreet marker is better than a heavy keyword like await. 2013/6/16 Mark S. Miller <erights at google.com> > I hadn't thought of the "urgent" implication -- interesting. I agree that > this has the contrary connotations which is unfortunate. > > E and AmbientTalk use "<-" which I always thought read well. In E, the > "then" concept is named "when" and is also supported as a syntactic form > using the "-> syntax. These work well together, as both indicate > asynchrony, with the direction of the arrow indicating what is eventually > being delivered to what. > > In JS, "a <- b" already parses as "a < -b" so introducing a "<-" token is > a non-starter. Process calculi languages like Pict (based on Pi Calculus), > and languages inspired by process calculi notions like Erlang and Scala use > an infix "!" for message sending, with the receiver on the left and the > payload on the right. This started with Tony Hoare's CSP (Communicating > Sequential Processes) and was picked up by Occam, where it was synchronous. > Technically it is synchronous in the Pi Calculus too. But in Pict, Erlang, > and Scala it is asynchronous. (Pict is based on the asynchronous subset of > the Pi Calculus.) > > More importantly for our audience, for JS (and similarly for Scala), > there's also a nice mnemonic rule: Wherever you can write an infix "." you > can write an infix "!" instead, changing the meaning of the construct from > synchronous to asynchronous. The "!" symbol has a "." at the bottom of it, > so you can think of it as "an enhanced dot" or even "a dot with a trail" if > you'd like. > > In any case, once the eye gets used to it the need for these mnemonics > rapidly drops away. Having lived with both "<-" and "!", I've come to > prefer the "!". I'm not really sure why. > > > > > On Sat, Jun 15, 2013 at 7:23 PM, Rick Waldron <waldron.rick at gmail.com>wrote: > >> >> >> On Saturday, June 15, 2013, Mark S. Miller wrote: >> >>> If we do provide such special syntax, then I suggest (a variant on some >>> else's suggestion -- I forget who) that "yield" is to "function* as "await" >>> is to "function!", amplifying the association of "!" with asynchrony. >>> Rather than say "async function" or whatever, we'd just say "function!". >>> Since "function!" would be new in ES7, there's no reason to reserve >>> anything in ES6 to prepare for this. >>> >> >> Mark, is there a particular rationale for the reuse of "!" as the >> eventual send operator and here for similar semantics? I recall this also >> appeared in you Distributed Electronic Rights paper. Putting its >> strong existing meaning aside (negation), when I see "!" I think >> of "urgent" things—quite the opposite of the behavior described in the >> paper and above. >> >> Rick >> >> >> >> >>> >>> >>> >>> >>> On Sat, Jun 15, 2013 at 2:40 AM, Bruno Jouhier <bjouhier at gmail.com>wrote: >>> >>> If this is on the agenda for ES7 maybe ES6 should at least reserve >>> "await" as a keyword in function* scopes. >>> >>> >>> 2013/6/15 François REMY <francois.remy.dev at outlook.com> >>> >>> I'm maybe biased, but I would love to consider "yield" as a function. >>> Indeed, it calls another code, which can return you a value. That looks >>> very similar to a function call to me. If we do this, the predecence >>> becomes intuitive again: >>> >>> var x = yield(a) + yield(b); >>> yield(a+b); >>> >>> I think there was a proposal to allow parenthesis-free function call at >>> some point at the root of a statement. When it lands, you'll be able to do >>> things like >>> >>> yield a+b; >>> >>> as a normal statement again. In the mean time we can just use >>> parentheses, that's not a huge issue and it helps clarity. >>> >>> >>> >>> But maybe this is too late to change ES6, it's just an idea I had while >>> reading this thread, not a strong call for change. >>> >>> >>> >>> >>> >>> >>> -----Message d'origine----- From: Brendan Eich >>> Sent: Saturday, June 15, 2013 6:17 AM >>> To: Dean Tribble >>> Cc: Bruno Jouhier ; es-discuss at mozilla.org >>> Subject: Re: Precedence of yield operator >>> >>> >>> This is all on the agenda for ES7. It cleanly missed ES6 in May 2011(!). >>> >>> https://mail.mozilla.org/**pipermail/es-discuss/2011-May/**014748.html<https://mail.mozilla.org/pipermail/es-discuss/2011-May/014748.html> >>> >>> /be >>> >>> Dean Tribble wrote: >>> >>> This is a familiar discussion from C#. I forwarded it to the mediator of >>> that convresation and got a nice summary, pasted here: >>> >>> ---------- Forwarded message ---------- >>> From: *Mads Torgersen* <Mads.Torgersen at microsoft.com <mailto: >>> Mads.Torgersen@**microsoft.com>> >>> Date: Fri, Jun 14, 2013 at 2:11 PM >>> Subject: RE: Precedence of yield operator >>> To: Dean Tribble <tribble at e-dean.com <mailto:tribble at e-dean.com>> >>> >>> >>> I’m not on the mailing list. Feel free to forward to it. >>> >>> In C# we have separate keywords too, and indeed the precedence differs >>> as described below. For “yield return” (our yield) the lower precendence >>> falls out naturally since it engenders a statement, not an expression. >>> >>> “await” is not a reserved keyword in C# either, but we managed to wedge >>> it in all the same. Just adding await as an operator would lead to all >>> kinds of ambiguity; e.g. “await (x)” could be a function call or an await >>> expression, and the statement “await x;” could be a variable declaration or >>> an await statement. >>> >>> However, in C# “await” is only allowed inside methods marked “async”, >>> and since there weren’t any of those around before the feature was >>> introduced, it is not a breaking change. Inside non-async methods, >>> therefore, “await” continues to be just an identifier. >>> >>> I don’t know if a similar thing is possible in EcmaScript. But I believe >>> that a low-precedence yield as a substitute for a high-precedence await is >>> problematic: you never want “yield a + yield b” to mean “yield (a + (yield >>> b))”: the things you await – Task, Promises, Futures, whatever you call >>> them – just don’t have operators defined on them, and it would be silly to >>> parse them as if they might and then give errors (at runtime in EcmaScript, >>> at compile time in e.g. TypeScript). >>> >>> Mads >>> >>> >>> On Fri, Jun 14, 2013 at 11:07 AM, Brendan Eich <brendan at mozilla.com<mailto: >>> brendan at mozilla.com>> wrote: >>> >>> Bruno Jouhier wrote: >>> >>> While playing with my little async/await library, I noticed >>> >>> -- >>> Cheers, >>> --MarkM >>> >> >> > > > > -- > Cheers, > --MarkM > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130616/fa47f9a7/attachment-0001.html>