4 ms·

Yeah, I'm just saying that referential transparency and immutability often turn into a lie, since this code: https://gist.github.com/k-bx/594a415a06fdd0fc3841

• mercurial 13y ago
  Er, but that's not the same 'a', it's two different bindings with the same name, and you should get: foo.hs:3:9: Warning: This binding for `a' shadows the existing binding bound at ... when you compile with -Wall.
  • k_bx 13y ago
    Yes. You're free to rename second a to b. The point I wanted to make is that it's the same getA, but anyone reading the code should understand that result binded to a and b will be different.
    • mercurial 13y ago
      Depending on the monad. If you are in Reader and getA == ask, a and b will have the same value. If you are in IO and getA == getLine, a and b may be different.
      • k_bx 13y ago
        The whole point I was talking about is that as soon as you're in monad, referential transparency becomes a bit a "lie", and a <- getA, b <- getA becomes non just analogous to a = getA(); b = getA();, but even worse in "referential transparency" sense.
        • chongli 13y ago
          Referential transparency is not a lie; getA is just a value. It could be substituted for its meaning without altering the program. For example, the following program: foo = do a <- getA putStrLn ("Hello, " ++ a ++ "!") where getA = do putStrLn "What is your name?" getLine Is equivalent to: bar = do a <- do putStrLn "What is your name?" getLine putStrLn ("Hello, " ++ a ++ "!")
          • k_bx 13y ago
            Yes, that's exactly what I was sayint 2 comments upper this thread: > The point I wanted to make is that it's the same getA, but anyone reading the code should understand that result binded to a and b will be different. So, while referrential transparency is still in place, programmer who reads the code will most likely care not about getA's result, but rather what will a and b get binded to, and in those terms it's just the same as good old a = getA(); b = getA();