The fact that [bigFORTH | http://bigforth.sf.net/] and the [Glasgow Haskell Compiler | http://www.haskell.org] produce binaries that are about equally performant is no coincidence. 

  

 * [Forth] has issues using local variables, but can maintain global state with ease. [Haskell] has issues using global state, but can maintain local variables with ease. To address these issues, [ANSI] [Forth] introduced a portable locals wordset, while [Haskell] uses monads to deal with global state. Both constructs are fully expressable in the core language, and both address (essentially) different sides of the same problem. 

  

 * [Forth] allows the compiler to be extended by fundamentally altering the compiler in terms of words written in the base language itself. [Haskell] utilizes monads for this same purpose. 

  

 * [Haskell] uses the <tt>>>=</tt> operator to compose the right-hand monadic function onto the results returned by the left-hand computation. Save for the threading of state this is ''normal function composition.'' In [Forth], which is described mathematically as a purely combinator-based language, composition is performed by concatenation – e.g., simply listing one word after another. Hence, both [Forth] and [Haskell] code can be expressed via function composition, and therefore, reasoned about algebraically. 

  

 * [Forth] allows one to freely alter the return stack. Return stack items are (usually) return addresses ie. (partial) continuations. Freely altering the return stack is dangerous and can produce unstable software. However, there are nonetheless distinct patterns of return stack manipulations you can use to produce ''extremely'' compact representations of fairly high-level control flow structures. This introduces the concept of "return conventions," as distinct from "calling conventions." It turns out that [Haskell] uses return conventions as well, under the hood, to optimize pattern matching in case and function evaluation. 

  

 !!! See Also