The last paragraph in the previous post says:
Then what about the feasibility of functional programming in golang? It's not so much to express logic in programming languages as to teach an idiot advanced mathematics.
Well, let's try to teach the idiot some advanced mathematics.
Tail call optimization
Project go_tailcall
Implement stackless mutually recursive functions via trampolining
Pattern matching?
Pattern matching is worth mentioning, though it's not as essential as the two features mentioned above.
A pattern matching expression will be translated to a decision tree after compilation, which is not possible without compile time code generation. Release 1.4 of golang includes a command called 'go generate' which is NOT part of go build. Although we can write a library to make some improvements, but it's still not a language level facility. So I'd rather write decision trees in plain control structures.
Another important feature related with pattern matching is exhaustiveness checking. Sum types(simulated with interface) in golang are open type, which is unchecked in the type system. But with the help of a higher order function to match all the branches of a sum type, exhaustiveness can also be ensured. That is, types can be closed manually.
Comments
comments powered by Disqus