I’ve come to like the pattern, too (having debugged too many rrc conditions in 
async code)

However, I’m pretty sure it can be implemented as an AST transformation, with 
inspiration from EA’s EA Async project: 
https://github.com/electronicarts/ea-async

(The implementation is left as an excercise tonthe reader)

-Jesper

> On 26 Mar 2018, at 08.34, David Dawson <[email protected]> 
> wrote:
> 
> Hi,
> 
> I do a load of async programming, in the JVM world, mostly using RxJava and 
> CompleteableFuture). Not so much GPars or Reactor these days, but the 
> principles are fairly portable.
> 
> I've noticed that since I started using typescript on the front end, getting 
> access to await/ async there has been really nice for cleaning up async code 
> (also, some .NET langs have similar systems). Of course, async is required in 
> that environment, but having it able to be read in a similar way to 
> synchronous code is very useful, removing the nesting.
> 
> I was wondering if anyone had though about syntax support for await/ async 
> use cases?
> 
> I know there's a load of libs around, I was just wondering about language 
> support.
> 
> The key thing for typescript is that it rewrites the JS when transpiled to 
> actually be async. I imagine that could be ASTd to work, or have language 
> support more deeply, not sure.
> 
> Perhaps a groovy version could look like this
> 
> String async myAsyncMethod() {
>   def future = .. // some future
> 
>   // instead of future.get()
>   future
> }
> 
> Within the context of a non async method, you get the wrapped type, probably 
> a CompleteableFuture
> 
> def nonAsyncMethod() {
>   CompleteableFuture<String> myString = myAsyncMethod()
> 
>   
> }
> 
> Within an async method, you get to use "await", which is rebuilt when 
> compiled to something async instead.
> 
> def async otherAsyncMethod() {
>    String myString = await myAsyncMethod()
>  
>    printn "My String is $myString"
> }
> 
> The key thing is to avoid thread blocking code within an async method. Thats 
> the whole point really.  So otherAsyncMethod would actually be generated out 
> as something like 
> 
> def otherAsyncMethod() {
>    CompleteableFuture<String> myString = myAsyncMethod()
>  
>    myString.thenApply {
>        printn "My String is $myString"
>    }
> }
> 
> The joy of this really appears when you have what amount to deeply nested 
> promises, this example is completely trivial. The possible problem may be 
> that we don't have a properly standardised "Promise".
> 
> Any thoughts?
> 
> David.

Reply via email to