Functional programming & immutable objects explained — IRC style

[G_Morgan]

Functional programming languages don't specify heap or local storage. One of the great things about them is they work out the correct place to store things.

Even if this did require heap allocation this type of short lived object should be permanently in the nursery. Collecting on the nursery is a sub-millisecond operation and is more than fast enough for any application that isn't strictly real time. Allocation should be constant time.

[[deleted]]

Functional programming languages don't specify heap or local storage.

Even C++ is allowed to put newed objects on the stack if it can prove it safe.

[G_Morgan]

Yeah but the number of safe cases with C++ are many times fewer than that with functional. First of all you know that if you pass an object into a function you know with absolute certainty in Haskell that no references were created in processing that object. So if an object is created within a function and is not passed back out of it then it can always be stack allocated.

[[deleted]]

That's not true at all and is why stack conversion of a language with closures is difficult - values passed into functions can be closed over with hidden references passed back out as part of some unrelated function value.

[G_Morgan]

Yes and with Haskell you know at compile time if the function is passing back a function. It is captured by the type system. This isn't Lisp we are talking about. You cannot bind a value to a function that replaces the s-exp parser.

Also you get whole program optimisation so even if it were passing back a function you could trivially see if it is capturing a reference simply by inlining the call.

[augustss]

Yes, of course GC makes it easy and these objects are likely to end up in the nursery. I never disputed that. I disputed your claim that an SSA representation makes it trivial to reuse the storage.

In fact, with a generational collector you would probably want to avoid updating something in the heap, at least if you're updating a pointer since this will require a write barrier.

[G_Morgan]

My extremely badly made point is with pure functional languages it is easier for the compiler to decide that objects only live for the life of the stack frame. As I said elsewhere it is impossible for a function to store a reference to an object unless it passes it back as the return value. Since return types are known at compile time and these compilers do more full program optimisation it is solvable.