161–170 of 196 posts
Earlier quoted context omitted.
The api is mandatory; it’s how async/await works.
So everybody has to implement a task for any alternative event loop and accept tasks from other implementation ?
Earlier quoted context omitted.
Any news on Project Loom? When to expect it available?
We should have a public repo you can use to build Loom (a prototype at this stage) in a couple of weeks.
Earlier quoted context omitted.
That model is called green threads. Continuation passing style means passing along your continuation to your callee, and is the implementation of the async model. But normal calls do pass their continuation: the return address, pushed on the stack, is the continuation function, and the stack itself is the scope, and together they are a closure. Make the stack a first class value that can be switched, and you get to c…
Green threads is very different from CPS actually both from an implementation and semantics point of view. In a CPS model the continuation is first class and is available at every single call point. In practice this would require heap allocating every single function frame, which is expensive and and a huge problem for interoperability (a smart compiler can turn it back to a traditional stack if the continuation is o…
Note that you don't get the continuation in hand for the async-everywhere advocated by GP, only blocking operations get the continuation, and most of those are implemented by the runtime.
Earlier quoted context omitted.
Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense. Future, Option, List, State/IO, etc. And the do-notation that some comments mention become a long list of flatMap/filter/map invocations. do { futRecord record.id) username = futRecord.map(record -> record.name) futResult This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languag…
I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.
However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.
Why does it have to be either one? Why not the possibility of choosing the implementation you want to solve the problem? A language where you could easily run whatever you want would have my vote. Not having it shoved down my throat (I’m looking at you JS). While it’s possible to build most of it yourself you should have the possibility to choose.
Be careful with this. I'm not saying you should not do it, but consider you'll have to design it very carefully. In python you can chose what event loop to hook to async/await, and hence we have gevent, qt, uvloop, twisted, asyncio, tornado, trio and curio as competing implementations. They are very difficult to mix, and their ecosystems are mostly isolated, dividing the man power to add features, fix bugs, provide s…
Earlier quoted context omitted.
Can you explain "this is less overhead than immediately suspending"? AFAICT Rust's approach is as low-overhead as it gets, since the inherent separation between future creation and future execution means that future creation doesn't need to have any cost at all. I'm also not sure it makes sense to refer to Rust's behavior as "immediately suspending", since it's not suspending anything: until someone chooses to start…
My understanding is that Rust uses LLVM coroutines[1]. In order to have the behavior where the function does not start executing immediately, you would follow the example that you can find by searching for "injected suspend point, so that the coroutine starts suspended". So what this looks like is: * Function call * The coroutine creates its frame (I believe this maps to "future creation".) * Function return (the inj…
Earlier quoted context omitted.
We should have a public repo you can use to build Loom (a prototype at this stage) in a couple of weeks.
What does such build produce? A JVM? A bytecode converter which produced code for existing JVMs?
Earlier quoted context omitted.
Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense. Future, Option, List, State/IO, etc. And the do-notation that some comments mention become a long list of flatMap/filter/map invocations. do { futRecord record.id) username = futRecord.map(record -> record.name) futResult This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languag…
I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.
Or could you show a counterexample please?
Earlier quoted context omitted.
I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.
For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados. However, I agree that the important step…
Earlier quoted context omitted.
So everybody has to implement a task for any alternative event loop and accept tasks from other implementation ?
Yep. You build your event loop to take structs implementing the Future trait. The futures don't care about the executor, and it's easy to switch from an event loop running on the current thread to a thread pool, if needed.