3 ms·
Do notation solves that problem!
by wbl 8y ago
Do notation solves that problem!
- IngoBlechschmid 8y agoCame here to say that. I think do notation (and applicative idioms) are easily one of the most-underappreciated features outside the Haskell community.
- yawaramin 8y agoScala has had monadic do-notation (called 'for-comprehensions') for a long time and OCaml has recently gained both monadic and applicative 'do notation' (called various things, but mostly 'let+ syntax'). Edit: Oh and F# has also had computation expressions for a long time.
- z1mm32m4n 8y agoIt’s even nicer in Haskell because not only does do-notation make code look clean, await is a function, not an operator. Want prefix await? Go for it! res <- await $ foo bar Want postfix? You can have that too! res <- foo bar & await Being “just a function” means it composes with everything else in the language, something the Rust languages designers have held in high regard when designing this. (But I also fully appreciate the design constraints that prevent Rust from using “just a method” or ”just a macro”)
- Rusky 8y agoDo notation does not solve that problem. It solves the problem of chaining `.and_then` calls, but this is one layer up- do notation would still require each of those awaits to be a separate `a <- b` "statement," which couldn't even be chained in the first place!
- yawaramin 8y agoYes, exactly, bindings shouldn't be chained. The whole point of do-notation i.e. syntax that looks like normal bindings is to make them look imperative so that our monkey brains can grok concurrent code easily. Making 'await' expression-oriented is missing the whole point of 'await'. You could have just kept using 'flat_map' or whatever macro.
- Rusky 8y agoWell, the real benefit of `await` in an imperative language is that it works inside/across all the usual imperative control flow- loops with break/continue, early return, etc. Whether it's an expression or a binding is mostly orthogonal to that.