> Am 12.09.2017 um 21:18 schrieb Adam Kemp :
>
>> On Sep 11, 2017, at 9:56 PM, Thorsten Seitz wrote:
>>
>> My hope would be for something along these lines:
>>
>> func createDownloadTasks(for urls: [URL]) -> [async Data] {
>> return urls.map { url in async downloadResource(url) }
>> }
>> fun
> On Sep 11, 2017, at 9:56 PM, Thorsten Seitz wrote:
>
> My hope would be for something along these lines:
>
> func createDownloadTasks(for urls: [URL]) -> [async Data] {
>return urls.map { url in async downloadResource(url) }
> }
> func await(all tasks: [async Data]) async -> [Data] {
>
My hope would be for something along these lines:
func createDownloadTasks(for urls: [URL]) -> [async Data] {
return urls.map { url in async downloadResource(url) }
}
func await(all tasks: [async Data]) async -> [Data] {
return tasks.map { task in await task }
}
-Thorsten
> Am 11.09.201
Sorry, I was away for a while so I couldn’t respond to this right away.
> On Aug 29, 2017, at 12:29 AM, Jonathan Hull wrote:
>
> If you are asking about how ‘async’ (which defers ‘await’) composes, it
> actually composes completely naturally… and I believe that should be
> provable.
Can you
On Aug 31, 2017, at 5:48 PM, Pierre Habouzit via swift-evolution
wrote:
>> Unlike the proposed future code the async code is not naturally parallel, in
>> the running example the following lines from the async code are run in
>> series, i.e. await blocks:
>>
>> let dataResource = await load
Thank you Pierre for writing this. I wanted to say this for a while, but I am
too busy these days to do it myself.
Guys, please don’t miss what he has to say:
> On Aug 31, 2017, at 5:49 PM, Pierre Habouzit via swift-evolution
> wrote:
>
> On real systems going wide concurrently (and I will n
> On Aug 27, 2017, at 6:02 PM, Howard Lovatt via swift-evolution
> wrote:
>
> The async/await is very similar to the proposed Future (as I posed earlier)
> with regard to completion-handler code, they both re-write the imported
> completion-handler function using a closure, the relevant senten
@Howard,
First, you comparison is unfair! You cannot compare on aproach using throws
error handle vs another wich ignore the error and get a optional back. The
correct code is:
func updateImage() async {
>
> let image: try? async preprocessImage(downloadImage()) ?? defaultImage
>
> let text = tr
On 30.08.2017 3:43, Howard Lovatt wrote:
@Vladimir,
Default values are a problem for await/async when combined with parallel running
because await returns a value and not an optional (unlike future's get). Below is a
more realistic code for parallel running and a default value using async/awai
Two comments:
1. I don't think `Future` typed arguments and returns are a big deal,
since they give you easy parallelism, timeouts, queue control, and cancel
and you just call `get` when you need a value.
2. Don't use `Future` typed arguments and returns where you don't want
parallelism etc.
I understand. But it’s quite problematic to have to write all Future returning
functions with Future inputs just to be able to support parallel computations.
It’s not how futures are using in C# and JavaScript.
> On 30 Aug 2017, at 03:02, Howard Lovatt wrote:
>
> @David,
>
> The signatures wo
Oops I missed some awaits out in the async/await version I just posted.
Correct async/await version for parallel execution is:
func updateImage() async {
let image: Image
async do { // Runs in parallel (async)
image = try async preprocessImage(await downloadImage()) // Need to wait
for download
@David,
The signatures would be:
func processImage(_ image: Future) -> Future
func translate(_ text: Future) -> Future
Inside `processImage` and `translate` you would `get` the values at the
point were needed so that downloadImage and downloadText run in parallel
(which is highly desirable).
@Vladimir,
Default values are a problem for await/async when combined with parallel
running because await returns a value and not an optional (unlike future's
get). Below is a more realistic code for parallel running and a default
value using async/await:
func updateImage() async {
let image: Im
I don’t think the examples are 100% equivalent. In your version with the Future
library, preprocessImage and translate need to accept futures as argument,
correct? That’s more restrictive than in my example code where async/await
specifically provide sugar over then. Plus I don’t understand why
On 29.08.2017 19:02, Wallacy via swift-evolution wrote:
In this example i think we lose clarity, just looking for the code we cant know if
this two line will run on parallel or not!
Also, image.get blocks the thread, in this case we need the await anyway! And `async`
can throws too... So the err
In this example i think we lose clarity, just looking for the code we cant
know if this two line will run on parallel or not!
Also, image.get blocks the thread, in this case we need the await anyway!
And `async` can throws too... So the error handler can be pretty similar.
let image = async prepro
@David,
Using the `Future` library based on GCD that I have previously posted your
example would be:
let image = preprocessImage(downloadImage()) // These first two lines
run in parallellet text = translate(downloadText())render(image:
image.get ?? defaultImage, text: text.get ?? defaultText)
T
If you are asking about how ‘async’ (which defers ‘await’) composes, it
actually composes completely naturally… and I believe that should be provable.
Any result from using ‘async’ has to have ‘await’ called on it before it can be
used. The key question is: what should we do if it is returned
> On 29 Aug 2017, at 02:22, Xiaodi Wu via swift-evolution
> wrote:
>
> On Mon, Aug 28, 2017 at 16:10 Adam Kemp via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
> I know what the proposal said. I’m making a case that there is value in doing
> it differently.
>
> The composabili
> On 28 Aug 2017, at 23:14, Jean-Daniel via swift-evolution
> wrote:
>
>
>> Le 28 août 2017 à 06:14, Howard Lovatt via swift-evolution
>> a écrit :
>>
>> One of the biggest incumbents in this space on the server side is Java and
>> its concurrency is based on futures and works very well (
It actually removes the need of implementing a future library, with proper
extension of collection types, we’ll be able to implement collect, zip, race,
map, flatMap etc... most probably part of the Stdlib
On Aug 28, 2017, 21:25 -0400, Howard Lovatt via swift-evolution
, wrote:
> I don't really
I don't really get your point ListenableFuture is a Future, so anything
using ListenableFuture is using Future. As I said in the original message
"... there are a lot of libraries built on top of basic futures ...".
I am pointing out that people actually use Future in Java as the building
block, e
On Mon, Aug 28, 2017 at 16:10 Adam Kemp via swift-evolution <
swift-evolution@swift.org> wrote:
> I know what the proposal said. I’m making a case that there is value in
> doing it differently.
>
> The composability of futures is valuable. Mixing and matching async/await
> with futures is also val
> Le 28 août 2017 à 06:14, Howard Lovatt via swift-evolution
> a écrit :
>
> One of the biggest incumbents in this space on the server side is Java and
> its concurrency is based on futures and works very well (though there are a
> lot of libraries built on top of basic futures).
Most serve
I know what the proposal said. I’m making a case that there is value in doing
it differently.
The composability of futures is valuable. Mixing and matching async/await with
futures is also valuable. The queue-returning behavior that you can get from
futures is also valuable, and building async/
We don't need to this now!
Again: (Using proposal words)
"It is important to understand that this is proposing compiler support that
is completely concurrency runtime-agnostic. This proposal does not include
a new runtime model (like "actors") - it works just as well with GCD as
with pthreads or
How would these anonymous types get composed? If I wanted to implement a
function that takes a collection of futures and wait on it, how would I do
that? That is, how would I implement the equivalent of C#’s Task.WhenAll and
Task.WhenAny methods?
More generally, how do you pass one of these typ
> On Aug 28, 2017, at 1:14 PM, Florent Vilmart wrote:
>
> I can see where you're going with that.
> For me, the big unknown (and unspecified so far) is
>
> func process() async -> Image { ... }
>
> let result = process() // what is result? CoroutineType ?
>
> or am I missing something here
And that's why I (and others) are suggesting:
func processImageData1a() async -> Image {
let dataResource = async loadWebResource("dataprofile.txt") // No future
type here... Just another way to call dispatch_async under the hood.
let imageResource = async loadWebResource("imagedata.dat")
I can see where you're going with that.
For me, the big unknown (and unspecified so far) is
func process() async -> Image { ... }
let result = process() // what is result? CoroutineType ?
or am I missing something here?
On 28 août 2017 16:07 -0400, Adam Kemp , wrote:
> I think the biggest trade
I think the biggest tradeoff is clearer when you look at the examples from the
proposal where futures are built on top of async/await:
func processImageData1a() async -> Image {
let dataResource = Future { await loadWebResource("dataprofile.txt") }
let imageResource = Future { await loadWebR
Yes I do think the async keyword to start execution without waiting is an
improvement, but would still like to have cancel, thread control, timeout,
and improved debugging.
-- Howard.
On 28 August 2017 at 13:21, Jonathan Hull wrote:
> What do you think of the idea that several of us have been
One of the biggest incumbents in this space on the server side is Java and
its concurrency is based on futures and works very well (though there are a
lot of libraries built on top of basic futures). Same goes for the Akka
library mentioned in the whitepaper, that is built on top of Scala's
futures
What do you think of the idea that several of us have been proposing on another
thread? In addition to being able to place ‘await' before an asynchronous
function, you could instead write ‘async’ which would simply allow you to defer
calling await (presumably until you need to await multiple it
Adam, you’re completely right, languages as c# and JS have been through the
path before, (callback, Promises , async/await) I believe Chris’s goal it to
avoid building a promise implementation and go straight to a coroutines model,
which is more deeply integrated with the compiler. I don’t see a
As has been explained, futures can be built on top of async/await (or the other
way around). You can have the best of both worlds. We are not losing anything
by having this feature. It would be a huge improvement to have this as an
option.
However, using futures correctly requires more nested
The async/await is very similar to the proposed Future (as I posed earlier)
with regard to completion-handler code, they both re-write the imported
completion-handler function using a closure, the relevant sentence from the
Async Proposal is:
"Under the hood, the compiler rewrites this code using
Also, as I re-read the proposal, the async/await would be implemented on top of
low level co-routines instead of the implementation we’ve seen in other
languages as a ‘child’ of Promises/Futures. So Futures or Promises would be a
freebee instead of the opposite. Wrapping cancellation would be st
This example still has nested closures (to create a Future), and still relies
on a synchronous get method that will block a thread. Async/await does not
require blocking any threads.
I’m definitely a fan of futures, but this example isn’t even a good example of
using futures. If you’re using a
The running example used in the white paper coded using a Future is:
func processImageData1() -> Future {
return AsynchronousFuture { _ -> Image in
let dataResource = loadWebResource("dataprofile.txt") //
dataResource and imageResource run in parallel.
let imageResource = load
> Le 26 août 2017 à 07:27, Howard Lovatt via swift-evolution
> a écrit :
>
> My argument goes like this:
>
> 1. You don't need async/await to write a powerful future type; you can use
> the underlying threads just as well, i.e. future with async/await is no
> better than future without.
>
Howard, with async / await, the code is flat and you don’t have to unowned/weak
self to prevent hideous cycles in the callbacks.
Futures can’t do that
On Aug 26, 2017, 04:37 -0400, Goffredo Marocchi via swift-evolution
, wrote:
> With both he now built in promises in Node8 as well as libraries l
With both he now built in promises in Node8 as well as libraries like Bluebird
there was ample time to evaluate them and convert/auto convert at times
libraries that loved callback pyramids of doom when the flow grows complex into
promise based chains. Converting to Promises seems magical for th
My argument goes like this:
1. You don't need async/await to write a powerful future type; you can
use the underlying threads just as well, i.e. future with async/await is no
better than future without.
2. Since future is more powerful, thread control, cancel, and timeout,
people should be en
> On Aug 25, 2017, at 12:34 AM, Howard Lovatt wrote:
>
> In particular a future that is cancellable is more powerful that the
> proposed async/await.
It's not more powerful; the features are to some degree disjoint. You can build
a Future abstraction and then use async/await to sugar code th
Using a Future library, see below, you can do what you want. In particular
a future that is cancellable is more powerful that the proposed
async/await. Here is an extended example of a typical UI task including
users cancelling tasks that is written using a future library (see below):
@IBOutle
I think that the solution you are describing is how RxSwift (ReactiveX)
solves this problem.
I believe Rx, like many other higher level abstractions would benefit from
async, actors behind the scenes, as an implementation detail.
בתאריך יום ד׳, 23 באוג׳ 2017 ב-20:41 מאת Joe Groff via swift-evol
> On Aug 19, 2017, at 4:56 AM, Jakob Egger via swift-evolution
> wrote:
>
> I've read async/await proposal, and I'm thrilled by the possibilities. Here's
> what I consider the canonical example:
> @IBAction func buttonDidClick(sender:AnyObject) {
> beginAsync {
> let image = await proces
Maybe this will be handled more gracefully via the actor model.
1. if you're calling from an actor, you'd be called back on its internal queue.
If you're calling from the 'main actor' (or just the main thread), you'd be
called back on the main queue
2. you would just add a cancel() method to the
I've read async/await proposal, and I'm thrilled by the possibilities. Here's
what I consider the canonical example:
@IBAction func buttonDidClick(sender:AnyObject) {
beginAsync {
let image = await processImage()
imageView.image = image
}
}
This is exactly the kind of thing I will use
51 matches
Mail list logo
