3 ms·

The do notation allows the reader to misunderstand code quite deeply, contorting sound, standard and relatively simple functional programming techniques and idi

The do notation allows the reader to misunderstand code quite deeply, contorting sound, standard and relatively simple functional programming techniques and idioms into an obfuscated and deceptive syntax that looks like something it is not.

tome 7y ago
An example would be probably make your case stronger.
- jhomedall 7y ago
  This: do x <- ["a","b","c"] y <- ["d","e","f"] return (x ++ y) evaluates to: ["ad","ae","af","bd","be","bf","cd","ce","cf"] Note that this is _not_ equivalent to: ["a", "b", "c"] ++ ["d", "e", "f"] which would instead evaluate to ["a","b","c","d","e","f"] The Python equivalent would be: [(a + b) for a in ["a", "b", "c"] for b in ["d", "e", "f"]] Which evaluates to: ['ad', 'ae', 'af', 'bd', 'be', 'bf', 'cd', 'ce', 'cf']
  - Raidion 7y ago
    As someone who does not program in functional languages, this really really helps clear up the article and surrounding discussion. Good stuff!
    - dllthomas 7y ago
      On the other hand, as someone with a bit of Haskell background, this doesn't even seem weird (except the use of String over Text).
tromp 7y ago
It's just syntactic sugar for Monad functions >>= and >> How can that be deeply misunderstood?
- whlr 7y ago
  Because it looks imperative.
  - whateveracct 7y ago
    ah so if you don't actually know what you're doing it could mislead you
  - pinopinopino 7y ago
    Do notation is jokingly called a programmable semicolon. True, it is often used to model imperative computations with it, so that is the association people have with it. Also people come mostly from imperative backgrounds and look, we can bind something to a value. Finally something I get! And that is fine, let them play around with it like that. But if they look closer, they find out it is not really imperative. Why is there a difference between let and bind? Why can't I reassign values. And they start to use more exotic and also more interesting monads and boom the imperative feel goes away. For example with the interesting LogicT[1] monad. Or what about the probability monad[2]? Or the continuation monad[3]? Or the reverse state monad[4]? How imperative are those really? It really depends how you use it. And I think it adds more to the magic, that you think it is just imperative code at first, because suddenly you can create code that behave very different under various monads that represent computation models. I think that is a cool thing about this confusion. I understand that if you are a professional that needs to get work done, it can be annoying. [1]https://hackage.haskell.org/package/logict https://hackage.haskell.org/package/logict [2]https://hackage.haskell.org/package/probability https://hackage.haskell.org/package/probability [3]https://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Monad-Cont.html https://hackage.haskell.org/package/mtl-2.2.2/docs/Control-M... [4]https://lukepalmer.wordpress.com/2008/08/10/mindfuck-the-reverse-state-monad/ https://lukepalmer.wordpress.com/2008/08/10/mindfuck-the-rev...

tome 7y ago

An example would be probably make your case stronger.

jhomedall 7y ago
This: do x <- ["a","b","c"] y <- ["d","e","f"] return (x ++ y) evaluates to: ["ad","ae","af","bd","be","bf","cd","ce","cf"] Note that this is _not_ equivalent to: ["a", "b", "c"] ++ ["d", "e", "f"] which would instead evaluate to ["a","b","c","d","e","f"] The Python equivalent would be: [(a + b) for a in ["a", "b", "c"] for b in ["d", "e", "f"]] Which evaluates to: ['ad', 'ae', 'af', 'bd', 'be', 'bf', 'cd', 'ce', 'cf']
- Raidion 7y ago
  As someone who does not program in functional languages, this really really helps clear up the article and surrounding discussion. Good stuff!
  - dllthomas 7y ago
    On the other hand, as someone with a bit of Haskell background, this doesn't even seem weird (except the use of String over Text).

tromp 7y ago

It's just syntactic sugar for Monad functions >>= and >> How can that be deeply misunderstood?

whlr 7y ago
Because it looks imperative.
- whateveracct 7y ago
  ah so if you don't actually know what you're doing it could mislead you
- pinopinopino 7y ago
  Do notation is jokingly called a programmable semicolon. True, it is often used to model imperative computations with it, so that is the association people have with it. Also people come mostly from imperative backgrounds and look, we can bind something to a value. Finally something I get! And that is fine, let them play around with it like that. But if they look closer, they find out it is not really imperative. Why is there a difference between let and bind? Why can't I reassign values. And they start to use more exotic and also more interesting monads and boom the imperative feel goes away. For example with the interesting LogicT[1] monad. Or what about the probability monad[2]? Or the continuation monad[3]? Or the reverse state monad[4]? How imperative are those really? It really depends how you use it. And I think it adds more to the magic, that you think it is just imperative code at first, because suddenly you can create code that behave very different under various monads that represent computation models. I think that is a cool thing about this confusion. I understand that if you are a professional that needs to get work done, it can be annoying. [1]https://hackage.haskell.org/package/logict https://hackage.haskell.org/package/logict [2]https://hackage.haskell.org/package/probability https://hackage.haskell.org/package/probability [3]https://hackage.haskell.org/package/mtl-2.2.2/docs/Control-Monad-Cont.html https://hackage.haskell.org/package/mtl-2.2.2/docs/Control-M... [4]https://lukepalmer.wordpress.com/2008/08/10/mindfuck-the-reverse-state-monad/ https://lukepalmer.wordpress.com/2008/08/10/mindfuck-the-rev...