Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Haskell gives you referential transparency and immutability guarantees, something you'll never get in Kotlin.

That said, I agree that Haskell code is typically dense, and suffers from readability problems.



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

could easily put 2 different values into `a` on each line. Of course, technically everything is still correct, and getA still returns same result for each call.


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.


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.


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.


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.


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 ++ "!")


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();




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: