Basically you don’t need mutation to have things that change. A state is a mapping of identifiers to values, that is a state is really just an enviroment.

Env { foo = 2,
baz = “boo”}

and an enviroment is really just a data structure.

To produce a change in an eviroment we take an old one and produce a new one. So

// Env now is same as above
foo ++; // the enviroment is being passed to foo implicitly
// foo has returned a new enviroment Env {foo = 3, baz = “boo”}

Since nobody is using the old enviroment it can be garbage collected. Better yet the old enviroment can be recylced. Notice how we are still using mutation but we are not using it directly. This is just like garbage collection vs memory management. In both cases memory is being managed but in the garbage collection case a correct program is being produced faster with less effort, because the computer is taking care of our memory for us.

In general we can represent time varying quantities by using sequences instead of mutation. So instead of using a loop to increment a value we write a pure function which takes the current state and produces the next state.

for (i=0; i [0, 1, 2, 3, 4, 5, 6........]
take 11 $ iterate foo 0 => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

I hope that was clear, though I’m not sure it was

Do you know what a data dependency is? It’s part of compiler implementation practise. Basically when a variable gets it value from somewhere it’s said to depend on where it got it from. In other words, in order for a function to use the value it must first evaluate the place it gets its value from first. In theory as long as you evaluate things depended on before you evaluate things that use that thing, your program should produce the same results no matter what order things are evaluated in.

But io doesn’t work like this, at least not in mainstream languages. So if change the order of evaluation of statements that do io, you’ll produce different results. So how does haskell fix this? By making things that must be evaluated in a certain order have data dependencies between each other. So now haskell can evaluate things in any way it wants, the way functional programming is supposed to work, so long as it respects the data dependencies. How does it acheive this? By making the result of a function use the result of previous functions.

This function is called bind, and in haskell is written >>=. It takes two functions as arguments. The first produces a result and the second takes a result and produces another one. Bind takes these two functions and joins them together.

A not entirely correct analogy, is that in many mainstream languages, arguments must be evaluated before being passed into a function. So if we have that rule and we want certain things to be done in a certain order we can make a function that does the last thing and pass it the result of doing to the next to last thing as an argument. Since arguments will be evaluated before the function they’re being passed to, the next-to-last function call will be evaluated before the last one. So basically bind takes two functions, which it names second (char second(int) {…}) and first (int first () {…}), and rewrites them so we have second(first). Does that kind of make sense?

See my next post for mutation vs functional

Paul said: “The difference between f(2) and g(fileSystem) is that there is nothing that f can do to “2″ that can cause people to die. There may be things that g can do to “fileSystem” that can cause people to die (whether due to software error or to correctly sending an email that launches a war).”

This is not a valid comment to make. What’s to say that the function f(2) isn’t a single line function that erases everything on your hard drive, without seeing the contents of that function you can’t know that. Even if you can see the function’s contents and it doesn’t seem to be doing that some error in the function could cause it to do that elsewhere.

Secondly when you were comparing abstractions and their “contents” or “real world representations” you’ve made a huge mistake. Interacting with the contents of a hard drive is akin to interacting with the contents of the “number two” which has drastic real world consequences. Think about it, since you were knee high to a grasshopper you’ve known what 2 means, it’s an abstraction with static contents that we as a society all agree on for ease of communication. If you change the contents of that abstraction (change the “meaning” behind the “number two”) even just within the scope of your system, think about the consequences.

This post isn’t changing the world as you know it, it’s merely looking at it from a different angle and questioning things you (and I) have taken for granted since the infant stage of programming and probably since the beginning of our interaction with a computer of any kind.

I’m reminded of when I first heard about lambda expressions and closures. It was this abstract weird bunch of jargon explained by even more jargon and I couldn’t make heads or tails of it. With some digging, I found the right explanation, the one that made me think, “Oh, that’s IT? Why didn’t they just SAY so?”.

I’m sure there’s an article out there about monads that would cut to the chase like that, but I haven’t found it yet.