Believe me, I know all about pattern matching, recursive functions, and all that fine functional programming stuff. If I wanted to write a recursive Fibonacci function, using an accumulator is the first thing that would come to mind. But that's not the point. I'm not asking anybody to throw out pattern matching, or recursion, or any of that. I'd just like to be able to write locally non-functional code.
Look at your native Erlang implementation of fib again. Would you say that it's easier to understand than the version I posted which uses a for loop? It uses an accumulator and an auxiliary tail-recursive function; I know you get used to writing like that after a while, but I'd like another option.
Haskell demonstrates conclusively that this is possible. We don't have to choose between pattern matching or mutable variables; we can have both, cleanly, as long as there's a way of keeping the mutable variables isolated in a safe box where they can't affect the rest of the program. In Haskell, this is the State or ST monad. In my proposal, mutable variables would be function-local, and such code is transformed to use tail-recursion. (This is what Haskell's State and ST monads do behind the scenes. The same could be done by a compiler with Erlang as the back-end.)
But why would you want to do that? This is the sort of madness that led C++ into hell. Sometimes '=' is this sort of operator, sometimes it is that. The old Perl maxim of make it possible to write the same thing in sixteen different ways is another fresh hell.
85% of the cost of softare is in code maintenance. Suddenly spawning multiple idioms for the same thing is madness. This proposal would directly increase the cost of running my software house - just not ever a good idea.
Look at your native Erlang implementation of fib again. Would you say that it's easier to understand than the version I posted which uses a for loop? It uses an accumulator and an auxiliary tail-recursive function; I know you get used to writing like that after a while, but I'd like another option.
Haskell demonstrates conclusively that this is possible. We don't have to choose between pattern matching or mutable variables; we can have both, cleanly, as long as there's a way of keeping the mutable variables isolated in a safe box where they can't affect the rest of the program. In Haskell, this is the State or ST monad. In my proposal, mutable variables would be function-local, and such code is transformed to use tail-recursion. (This is what Haskell's State and ST monads do behind the scenes. The same could be done by a compiler with Erlang as the back-end.)