<div dir="ltr">Hi Bruno, yes the idea is to use the infix ! for async calls, but not in quite the way you mean. Have you seen <<a href="http://wiki.ecmascript.org/doku.php?id=strawman:concurrency">http://wiki.ecmascript.org/doku.php?id=strawman:concurrency</a>> and <<a href="http://research.google.com/pubs/pub40673.html">http://research.google.com/pubs/pub40673.html</a>> ?<div>
<br></div><div style>The basic idea is that without syntactic support, today in Q to send an asynchronous message, you'd say</div><div style><br></div><div style>    Q(p).send('foo', a,b)</div><div style><br></div>
<div style>In what has been codified of DOM promises, you'd say</div><div style><br></div><div style>    Promises.accept(p).then(o => o.foo(a,b))</div><div style><br></div><div style>which wouldn't even work distributed, since there is no local o on which to do a local ".". Both of these are so much heavier than </div>
<div style><br></div><div style>    p.foo(a,b)</div><div style><br></div><div style>as to make asynchronous and distributed programming remain second class compared to local synchronous programming. So the full proposal is that</div>
<div style><br></div><div style>    p ! foo(a,b)</div><div style><br></div><div style>would mean to eventually send the message on the right to the receiver designated on the left. Likewise for</div><div style><br></div><div style>
    p ! (a,b) // asynchronous function call</div><div style>    p ! foo // asynchronous get</div><div style>    p ! foo = x // asynchronous put</div><div style>    delete p ! foo // asynchronous delete</div><div style><br>
</div><div style>and the computed forms of all these</div><div style><br></div><div style>    p ! [name] (a,b)</div><div style>    p ! [name]</div><div style>    p ! [name] = x</div><div style>    delete p [name]</div><div style>
<br></div><div style>Over a RESTful transport <<a href="http://waterken.sourceforge.net/web_send/">http://waterken.sourceforge.net/web_send/</a>>, these would turn into POST, GET, PUT, and DELETE. Fortunately or unfortunately, because of CORS and UMP (something they agreed on), I expect RESTful PUT and DELETE to wither away and die in browser-to-server traffic. Our recent electronic rights paper uses only POST and GET, even though it uses only server-to-server traffic. If it can't practically be used browser-to-server, I expect it won't be used much server-to-server. Nevertheless, we should keep these forms of "!" in the language.</div>
<div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 16, 2013 at 2:26 AM, Bruno Jouhier <span dir="ltr"><<a href="mailto:bjouhier@gmail.com" target="_blank">bjouhier@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Why not use the ! marker both for function declarations and function calls then:<br><br></div>
  function! foo(a, b) { }<br></div><div>  var v = foo!(a, b);<br><br></div><div>Of, for better symmetry:<br>
<br>  function foo!(a, b) { }<br>  var v = foo!(a, b);<br><br></div><div>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.<br>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/16 Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span><div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I hadn't thought of the "urgent" implication -- interesting. I agree that this has the contrary connotations which is unfortunate.<div><br></div><div>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.</div>


<div><br></div><div>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.)</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div><br></div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Sat, Jun 15, 2013 at 7:23 PM, Rick Waldron <span dir="ltr"><<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><br>On Saturday, June 15, 2013, Mark S. Miller  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr">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.</div>



</blockquote><div><br></div></div><div>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. <span></span>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.</div>



<div></div><div><br></div><div>Rick</div><br><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>
<br><div class="gmail_extra"><div><div><br><br><div>On Sat, Jun 15, 2013 at 2:40 AM, Bruno Jouhier <span dir="ltr"><<a>bjouhier@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If this is on the agenda for ES7 maybe ES6 should at least reserve "await" as a keyword in function* scopes. <br>




</div><div><div><div><br><br><div>2013/6/15 François REMY <span dir="ltr"><<a>francois.remy.dev@outlook.com</a>></span><br>

<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>






<br>
   var x = yield(a) + yield(b);<br>
   yield(a+b);<br>
<br>
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<br>
<br>
   yield a+b;<br>
<br>
as a normal statement again. In the mean time we can just use parentheses, that's not a huge issue and it helps clarity.<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
<br>
-----Message d'origine----- From: Brendan Eich<br>
Sent: Saturday, June 15, 2013 6:17 AM<br>
To: Dean Tribble<br>
Cc: Bruno Jouhier ; <a>es-discuss@mozilla.org</a><br>
Subject: Re: Precedence of yield operator<div><div><br>
<br>
This is all on the agenda for ES7. It cleanly missed ES6 in May 2011(!).<br>
<br>
<a href="https://mail.mozilla.org/pipermail/es-discuss/2011-May/014748.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/es-discuss/2011-May/<u></u>014748.html</a><br>
<br>
/be<br>
<br>
Dean Tribble wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is a familiar discussion from C#. I forwarded it to the mediator of that convresation and got a nice summary, pasted here:<br>
<br>
---------- Forwarded message ----------<br>
From: *Mads Torgersen* <<a>Mads.Torgersen@microsoft.com</a> <mailto:<a>Mads.Torgersen@<u></u>microsoft.com</a>>><br>


Date: Fri, Jun 14, 2013 at 2:11 PM<br>
Subject: RE: Precedence of yield operator<br>
To: Dean Tribble <<a>tribble@e-dean.com</a> <mailto:<a>tribble@e-dean.com</a>>><br>
<br>
<br>
I’m not on the mailing list. Feel free to forward to it.<br>
<br>
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.<br>
<br>
“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.<br>






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






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






<br>
Mads<br>
<br>
<br>
On Fri, Jun 14, 2013 at 11:07 AM, Brendan Eich <<a>brendan@mozilla.com</a> <mailto:<a>brendan@mozilla.com</a>>> wrote:<br>


<br>
    Bruno Jouhier wrote:<br>
<br>
        While playing with my little async/await library, I noticed<br></blockquote></div></div></blockquote></div></div></div></div></blockquote></div></div></div><span><font color="#888888">-- <br>    Cheers,<br>
    --MarkM
</font></span></div></div></div></blockquote><div> </div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>    Cheers,<br>    --MarkM
</font></span></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div>