If you have mutable state then you can't guarantee referential transparency. "Are these the same object" isn't interesting because the behaviour of your program can't vary with the answer, whereas with mutable state, the behaviour of your program can vary with the answer (this is aliasing). When you have immutable objects, the question "are these the same object" seems a bit pointless, whereas "are these the same value" is always relevant. This seems to go hand-in-hand with mutable state, because the questions "are these the same object" and "are these the same value" are both relevant. Object systems do have a notion of object identity. are these the same box? All it has is an equality operator (=), which is only concerned with the box contents. But Haskell has no way of saying "are these the same object?" i.e. When you pass this value to functions, you pass the box, so it could be considered a reference. When you construct a value (an instance of a type), the constructor creates a box (pointer) around the value. Haskell also has no notion of object identity. Also, you avoid any aliasing problems, which is a potential cause of errors in programs that use mutable state. This isn't as expensive as it sounds, due to the extensive data sharing that immutable objects make possible (the bits of the object that aren't modified aren't copied you just retain the references to the originals). When you want to change an object, you make a copy of it and replace just the bits you want to change. All you can do is construct new objects (this makes the term "data constructor" seem more relevant).
6 I'm an OO programmer - how do I design Haskell programs?Ī Haskell program is like an OO program where every object is immutable.
0 kommentar(er)
