Timeline for Why don't programming languages automatically manage the synchronous/asynchronous problem?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2019 at 21:19 | audit | First posts | |||
| Apr 13, 2019 at 10:06 | |||||
| Mar 31, 2019 at 12:00 | comment | added | Voo | @Jörg That seems like it would be problematic in anything but functional languages since you have no way of knowing when code is actually executed in that model. That generally works fine in say Haskell, but I can't see how this would work in more procedural languages (and even in Haskell, if you care about performance you sometimes have to force an execution and understand the underlying model). An interesting idea nevertheless. | |
| Mar 29, 2019 at 17:03 | comment | added | Jörg W Mittag |
@amon: The idea of Transparent Futures is that you don't know it's a future. From your point of view, there is no common interface between Future<T> and T because from your point of view, there is no Future<T>, only a T. Now, there is of course lots of engineering challenges around how to make this efficient, which operations should be blocking vs. non-blocking, etc., but that is really independent of whether you do it as a language or as a library feature. Transparency was a requirement stipulated by the OP in the question, I won't argue that it is hard and might not make sense.
|
|
| Mar 29, 2019 at 17:01 | comment | added | Jörg W Mittag | @Cinn: Yes, you can do that with Transparent Futures, and you don't need any special language features to do that. You can implement it using the already existing features in e.g. Smalltalk, Self, Newspeak, Us, Korz, Io, Ioke, Seph, ECMAScript, and apparently, as I just read, Python. | |
| Mar 29, 2019 at 16:56 | comment | added | Cinn |
I understand that it does not add any features, the thing is we have different syntaxes to write immediately resolving computations and long-running computations, and after that we would use the results the same way for other purposes. I was wondering if we could have a syntax that transparently handle the both, making it more readable and so the programmer does not have to handle it. Like doing a + b, both integers, no matters if a and b are available immediately or later, we just write a + b (making possible to do Int + Future<Int>)
|
|
| Mar 29, 2019 at 16:47 | comment | added | amon |
Ok, but that has problems if both Future<T> and T share some common interface and I use functionality from that interface. Should it become the result and then use the functionality, or not? I'm thinking of things like an equality operator or a to-string debugging representation.
|
|
| Mar 29, 2019 at 16:44 | history | answered | Jörg W Mittag | CC BY-SA 4.0 |