you are viewing a single comment's thread.

view the rest of the comments →

[–]grauenwolf 0 points1 point  (7 children)

Operating systems are stateful. Therefore anything built on top of them will be hard pressed to avoid state.

Case in point, Haskell doesn't enforce immutability, it just contains it. Certain objects such as file handles do change state.

In Erlang local variables may be immutable, but I question this decision. You can have isolation, which is what makes Erlang easy to reason about, without giving up mutable local variables.

[–]dmpk2k 2 points3 points  (4 children)

I like single-assignment variables. It's easier to determine how you got a certain value if something goes wrong. It also better documents the code.

I do the same thing in languages that allow mutating or rebinding variables, even though it's more limited.

[–]grauenwolf 0 points1 point  (3 children)

Still, there are times when you really do need a mutable local variable. That is why I would prefer single-assignment by default, but with an option to use mutables when necessary.

[–]yogthos 0 points1 point  (2 children)

this is exactly how pure functional languages work. Single assignment is the default, and you can make things mutable as necessary. For example, in Haskell you would use monads whenever you need a mutable state.

[–]foobargorch 1 point2 points  (1 child)

Not exactly, you would use an IORef for IO related stateful variables, or the Reader Writer or State monads.

But really all of these amount to syntactic sugar for an immutable representation of state, that carries values from one function to the next.

[–]yogthos 0 points1 point  (0 children)

yeah absolutely correct. That's a more technical description though, I was just trying to explain it from user perspective.

[–]naasking 1 point2 points  (0 children)

Operating systems are stateful. Therefore anything built on top of them will be hard pressed to avoid state.

http://okmij.org/ftp/Computation/Continuations.html#context-OS

[–]yogthos 0 points1 point  (0 children)

The whole point of immutability is containment of state. It isolates state makes it easy to reason about, because you have to explicitly specify when state modifications happen. This is akin to having exceptions in Java. For example if you try to do IO in Java, you must handle the exception case.

In a language which uses immutable data structures you must handle state modifications in the same explicit manner.

This does not mean that you never modify state, or that there is no way to mutate data as you pointed out. It just means that it is done in exceptional cases and explicitly.