3 ms·

I liked this, it is one of the clearest explanations of tail call optimisation I've read. It explains that it removes the need for recursively more stack spac

by Nick_C 16y ago

I liked this, it is one of the clearest explanations of tail call optimisation I've read. It explains that it removes the need for recursively more stack space, and therefore why it's a Good Thing. As an aside, I also liked his note on why we don't use functional languages more. http://tratt.net/laurie/blog/entries/why_dont_we_use_functional_programming_languages_more http://tratt.net/laurie/blog/entries/why_dont_we_use_functio...

hga 16y ago
Hmmm, I don't find the latter that useful. It's more a "Why we don't use Hackell more" essay, since the problematic things he cites are not present in many other functional languages (pervasive laziness and the sharp delineation of state changing code). Particularly in the original functional programming language family of LISP (which, I grant you, has been multiparadigm from the beginning). Even in the most functional most successful branch of Clojure things are somewhat friendlier (although it's new enough plenty of practical programming warts still need attention). It's my strong impression that for a long time Haskell has been as advertised in an "Avoid Success At All Costs!" mode so that various particularly pure things could be explored. The ML family might be more worthy of examination along the lines of the author, particularly with F#'s elevation to first class status in the Microsoft .NET ecosystem.
hga 16y ago
The problem with stack-backtraces and TCO has been well known for a long while (early 80s?) and it's indeed a serious issue. It's also related to what I've read about the delay in adding TCO to JVMs: by its very nature it rewrites the stack, and confirming the safety and security of that (which a serious JVM is required to do) is not entirely trivial. It was considered for Java 7 and will hopefully get into Hotspot someday.

by Nick_C 16y ago

hga 16y ago

Hmmm, I don't find the latter that useful. It's more a "Why we don't use Hackell more" essay, since the problematic things he cites are not present in many other functional languages (pervasive laziness and the sharp delineation of state changing code). Particularly in the original functional programming language family of LISP (which, I grant you, has been multiparadigm from the beginning). Even in the most functional most successful branch of Clojure things are somewhat friendlier (although it's new enough plenty of practical programming warts still need attention). It's my strong impression that for a long time Haskell has been as advertised in an "Avoid Success At All Costs!" mode so that various particularly pure things could be explored. The ML family might be more worthy of examination along the lines of the author, particularly with F#'s elevation to first class status in the Microsoft .NET ecosystem.

hga 16y ago

The problem with stack-backtraces and TCO has been well known for a long while (early 80s?) and it's indeed a serious issue. It's also related to what I've read about the delay in adding TCO to JVMs: by its very nature it rewrites the stack, and confirming the safety and security of that (which a serious JVM is required to do) is not entirely trivial. It was considered for Java 7 and will hopefully get into Hotspot someday.