Why do functional programming languages require garbage collection? What's stopping ghc from translating Haskell into a concatenative programming language such as combinatory logic and then simply using stack allocation for everything? According to Wikipedia, the translation from lambda calculus to combinatory logic is trivial, and also, concatenative programming languages can rely solely on a stack for memory allocation. Is it feasible to do this translation and thus eliminate garbage collection for languages such as Haskell and ocaml? Are there downsides to doing this?

EDIT: moved here https://stackoverflow.com/questions/39440412/why-do-functional-programming-languages-require-garbage-collection
All of the following comments are premised on the choice of a standard implementation strategy using closures to represent function values and a call-by-value evaluation order:


For the pure lambda calculus, garbage collection is not necessary. This is because it is not possible to form cycles in the heap: every newly-allocated value can only contain references to previously-allocated values, and so the memory graph forms a DAG -- so reference counting suffices to manage memory.
Most implementations do not use reference counting for two reasons. 


They support a form of pointer type (eg, the ref type constructor in ML), and so true cycles in the heap can be formed.
Reference counting is much less efficient than garbage collection, since 


it requires a lot of additional space to keep the reference counts, and 
updating the counts is usually wasted work, and 
the updates to the counts create a bunch of write contention which kills parallel performance.


Linearly-typed languages can eliminate the reference count (essentially because counts are 0-1: either the value has a single reference to it or it is dead and can be freed). 
However, stack allocation still does not suffice. This is because it is possible to form function values which refer to free variables (i.e., we need to implement function closures), if you allocate things on the stack, then live values can be interleaved with dead values, and this will cause incorrect asymptotic space usage. 
You can get the right asymptotics by replacing a stack with a "spaghetti stack" (ie, implement the stack as a linked list in the heap, so that you can cut out dead frames as needed).
If you want a real stack discipline, you can use type systems based on "ordered logic" (essentially linear types minus exchange).