3 ms·
Haskell's system (with the io monad + do not all monads or in general) is extremely similar to async/await and most languages with co-routines can simulate do n
by inglor 5y ago
Haskell's system (with the io monad + do not all monads or in general) is extremely similar to async/await and most languages with co-routines can simulate do notation in Haskell pretty well syntactically.
The advantage of something like JavaScript's async/await over Haskell's "do" is the fact because async/await is more limited than `do` (or yield and coroutines in JS) it's a lot easier to create tooling for.
- kaba0 5y agoI would say it is a huge disadvantage -- do is just syntactic sugar for a monad expression of binds, which is a native part of the language, you can write a simple function to manipulate it however you like. While you would need to effectively parse AST in case of JS.
- inglor 5y ago`yield` is just syntactic sugar for the two-way generator communication protocol where the consumer calls `.next(value)` which returns a value in turn. This is as expressive and you can build `do` semantics on top of stuff like lists/either/state/io on top of it. No AST parsing needed.
- kaba0 5y agoAnd do syntax sugar is just nested calls of `bind` which is a function of the Monad trait. Lists are also a Monad, so do notation just works right now with lists, either, state everything in Haskell. I really don’t get how is Haskell “behind”.
- ImprobableTruth 5y ago> async/await is more limited than `do` (or yield and coroutines in JS) it's a lot easier to create tooling for. What kind of tooling are you referring to?
- inglor 5y agoBasically by limiting the scope significantly and limiting it to language-level Promises you can create things like zero-cost async stack traces, async-call aware flame graphs and more for analysis and better lint rules and more specific types for development.