4 ms·
Yes, it has no effect on "correctness". The two are equivalent. But your example is nonsensical. If you scale this up to non-trivial problems I have a hunch
by nightski 13y ago
Yes, it has no effect on "correctness". The two are equivalent. But your example is nonsensical. If you scale this up to non-trivial problems I have a hunch we'd find this pervasively affects the design losing the ability to compose functions. It implies an ordering on the "dependencies/ownership" of the program.
Once you write your program, if a program is fully SSA you are right it is equivalent to an immutable one. However this affects how one designs the software in the first place. You would not write the code the same with the different tool-sets.
I have struggled with this because working in Haskell taking Rusts approach seems very appealing as it allows mutability. But every time I just come to the conclusion that it is a bad idea as it will end up greatly affecting modularity and composability.
To give an example. If I have a pure function A, which now calls function B which mutates a value, function A is no longer pure. Now you lose the ability to compose that function in many ways. This would happen all over the program.
- jerf 13y agoIf I'm reading your post correctly, what you're calling "nonsensical" is deliberately part of my point; you may want to re-read my post in light of that fact. The difference between a local context and a fully-composed program in a conventional mutable language is a core part of my argument, not something I overlooked.
- nightski 13y agoWhat I am saying is mutability is not something that tends to stay local. Either you isolate it at the top, ala Haskell or it tends to find it's way into everything. SSA is great, except that as you say it is functionally equivalent to immutability. There is no advantage to it over using immutable data structures. In fact, it is inferior as it only covers a subset of problems that immutability does. The examples in the blog post illustrate this. He wants to make local variables mutable because otherwise he can't pass a reference to a function which mutates a value. That mutation is completely unnecessarily and could of been performed with a pure function instead. Note the blog author says: "Think: when was the last time you responded to a compiler error about illegal mutation by doing anything other than restructuring the code to make the mutation legal?" I actually do this all the time. That is probably the largest challenge coming to a language like Haskell from an imperative background. Sometimes you can't just fix the little mutability problem locally, it has to be redesigned with immutability in mind.