I heard that Haskell variables are immutable but i am able to reassign and update variable values [duplicate] - variables

Question

This question already has an answer here:
Haskell: What is immutable data?
(1 answer)
Closed 4 years ago.
I heard that Haskell variables are immutable but i am able to reassign and update variable values

Answer 1

First, note that GHCi syntax is not quite the same as Haskell source-file syntax. In particular, x = 3 actually used to be illegal as such:
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> x = 3
<interactive>:2:3: parse error on input ‘=’
Newer versions have made this possible by simply rewriting any such expression to let x = 3, which has always been ok:
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> let x = 3
Prelude> x
3
By contrast, in a Haskell source file, let x = 3 has never been legal by itself. This only works in a particular environment, namely a monadic do block.
main :: IO ()
main = do
let x = 3
print x
3
And the GHCi prompt by design actually works like the lines in a do block, so let's in the following discuss that. Note that I can also write
main = do
let x = 1
let x = 3
print x
3
And that's basically what's also going on in your GHCi session. However, as the others have remarked, this is not mutation but shadowing. To understand how this works, note that the above is essentially a shorthand way of writing
main =
let x = 1
in let x = 3
in print x
So, you have two nested scopes. When you look up a variable in some expression, Haskell always picks the “nearest one”, i.e. in the inner scope:
main =
let x = 1
┌──
in│let x = 3
│in print x
└─
The outer x isn't touched at all, it's basically unrelated to anything going on in the inner scope. The compiler will actually warn you about this, if asked if there's anything fishy in your file:
$ ghc -Wall wtmpf-file16485.hs
[1 of 1] Compiling Main ( wtmpf-file16485.hs, wtmpf-file16485.o )
wtmpf-file16485.hs:3:8: warning: [-Wunused-local-binds]
Defined but not used: ‘x’
|
3 | let x = 1
| ^
wtmpf-file16485.hs:3:12: warning: [-Wtype-defaults]
• Defaulting the following constraint to type ‘Integer’
Num p0 arising from the literal ‘3’
• In the expression: 3
In an equation for ‘x’: x = 3
In the expression:
do let x = 1
let x = 3
print x
|
3 | let x = 1
| ^
wtmpf-file16485.hs:4:8: warning: [-Wname-shadowing]
This binding for ‘x’ shadows the existing binding
bound at wtmpf-file16485.hs:3:8
|
4 | let x = 3
| ^
There: the second definition simply introduces a new, more local variable which also happens to be called x, but is unrelated to the outer variable. I.e. we might as well rename them:
main = do
let xOuter = 1
let xInner = 3
print xInner
A consequence of all this is that a variable that's “mutated” in this way has no influence on other functions which use the original variable. Example:
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/sagemuej/.ghci
Loaded GHCi configuration from /home/sagemuej/.ghc/ghci.conf
Prelude> let x = 1
Prelude> let info = putStrLn ("x is ="++show x++" right now")
Prelude> x = 3
Prelude> info
x is =1 right now
Another consequence is that “updates” which try to use the old value behave in a funny way:
Prelude> let s = "World"
Prelude> s = "Hello"++s
Prelude> s
"HelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHell^C
Here, the new binding does not just prepend "Hello" to the old s="World". Instead, it prepends "Hello" to its own result value, which is in turn defined by "Hello" prepended to... and so on, recursively.

Answer 2

You're shadowing, not mutating.