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

Currying and Uncurrying

Project go_currying

Create typesafe curried/uncurried versions of functions

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.

- ZAN DoYe


Comments

comments powered by Disqus

© 2024 ZAN DoYe