17

According to Wikipedia, the translation from lambda calculus to combinatory logic is trivial. Concatenative programming languages can rely solely on a stack for memory allocation.

What's stopping GHC from translating Haskell into a concatenative programming language, such as combinatory logic, and then simply using stack allocation for everything?

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?

nbro
  • 15,395
  • 32
  • 113
  • 196
grasevski
  • 2,894
  • 2
  • 21
  • 22
  • 1
    Possible duplicate of [Does Haskell require a garbage collector?](http://stackoverflow.com/questions/9952602/does-haskell-require-a-garbage-collector) – Luka Rahne Sep 11 '16 at 21:17
  • 2
    I think it'd be pretty tough to implement Haskell's graph-rewriting semantics without something resembling a heap – Benjamin Hodgson Sep 11 '16 at 23:41

2 Answers2

8

Suppose I have a function that generates a linked list of some size. The size is the function parameter.

The question is: where do I have to allocate memory for the list? I can't allocate it on the function's stack, since it's invalid after the function is out. And I can't allocate it on the caller's stack, since I don't know how many memory I need to allocate before the function call. So I need to allocate it on the heap.

I think there may be RAII with manual heap management usable, But I can't see how to eliminate heap allocation at all.

Edit

I can't fit all my thoughts in the comment, so I write them here.

There is no magic about stack-based allocation languages. You still need to know when your data is relevant and remove them when they're not.

Imagine you have a separate stack, and your function has control to push and pop data in it. First, there is no automatic memory management anymore, i.e. the function terminates but the data is not deallocated automatically. Second, if you function allocates some memory, needed to support e.g. the list calculation, then all that stuff will be shuffled with the list that you want to return. No chance you can free unused memory (other lists, trees or so) since you have just push and pop operations. If you have other operations, then what is the difference with the heap?

What about few stacks, not one?

You need to allocate them somewhere, manage their growth and sometimes get them back. That stacks are separate constructions that you need manage by hands. No automatic memory management.

Stack-based languages are ok, but forget about the huge amount of algorithms, that was invented with the concept "get memory from somewhere" and "put the memory back", like hash maps, red-black trees, linked lists. Of course, we can allocate all of those structs on a stack, but we can't free their parts if they don't need anymore.

What about "trivial" lambda calculus translation to Turing machine?

Of course, it is trivial, if you resources are infinite. The math theory clarifies nothing about time and memory complexity of such translated constructions. It just approves that both of that models are equivalent, and all that we can say with Turing machine we can say with lambda calculus, and vice-versa. No guarantees that it can work with real-life limitations.

nbro
  • 15,395
  • 32
  • 113
  • 196
a.yekimov
  • 316
  • 1
  • 8
  • My understanding is that concatenative languages (which generally just use a stack) could in principle return a variable amount of data by popping and pushing to the stack, e.g. every function basically has the definition 'void foo(stack *s)'. – grasevski Sep 11 '16 at 21:46
  • Every function can rise it's stack, but not the caller's stack. Caller needs to know how many memory it needs to allocate for return value before any function may be called. – a.yekimov Sep 11 '16 at 21:52
  • Then how do stack based programming languages work? I think it's implemented as a separate stack for function calls and a separate stack for data, so this problem never arises. I.e. Like the c declaration I provided. – grasevski Sep 11 '16 at 23:28
  • The presence of heap allocations does not imply the presence of garbage collection. Most notably, the programming language `C` has heap allocations, but no garbage collector. So this answer is completely missing the question which doesn’t ask about whether a heap is needed, but whether (or why) garbage collection is needed. – Holger Sep 13 '16 at 13:56
  • I just pointed that you need manage your memory regardless the language you use. GC is just very handy. And I pointed that you can't just translate your lambdas without need to manage memory by hands or automatically with GC, as authour of the question suggested. – a.yekimov Sep 13 '16 at 14:03
7

A concatenative programming language is every bit as capable of running out of memory as a functional programming language.

The fundamental challenge garbage collection addresses is freeing memory that is not, or is not known to be, used in a stack-like fashion. It is most especially useful when there is no clear place in the source code that can be pinpointed as the end of the object's lifetime.

If you simply translate a functional language into a concatenative one with only stack allocation, then you will end up overflowing the stack.

There have definitely been various efforts over the years to reduce the need for garbage collection. One interesting (but very complicated) attempt is the region inference system used in the ML Kit. Unfortunately, that's a bit much for most programmers, including myself, to understand. I believe others have worked on such systems since; I don't know the current state of the art.

The take-away is that some very heavy compiler machinery, along with careful programmer discipline and perhaps special annotations, can sometimes reduce or eliminate the need for garbage collection; no trivial transformation is going to do the trick.

dfeuer
  • 48,079
  • 5
  • 63
  • 167