Lambda the Ultimate

A side note for audience: an introduction to finalizers Destructors, Finalizers, and Synchronization was left without any discussion. Should we crosslink these threads? :-)

Rather than going down that path, I would much prefer to see significant R&D effort put into the development of imperative-style data structures and algorithms in a way that doesn't require finalization. I have experimented with some of these issues myself.

Here are some thoughts.

File handles: If you are going to just open a file, do a bunch of operations, and close it, you could use a monad encapsulation similar to the way Haskell's State works, enabling opening the file, performing operations, and closing it, in a way that's guaranteed to result in the file being closed when exiting the lexical scope in which it was created.

But much more interesting is the possibility of using memory mapped files, and treating file-opening calls as returning a (possibly mutable) array of bytes which you can operate on. Then the memory mapped file would be closed when the array is eventually garbage collected. The big problem here is that in current file-mapping implementations, holding a file handle isn't referentially transparent: another process can observe whether the file is locked. This could be remedied by adding support in the OS for "tear-off" file mappings which memory map the file and then make it appear to the outside world that the file is closed (for example, so another process could modify it or delete it without a sharing violation). In this case, the OS paging mechanism would need to implement a copy-on-write-or-delete scheme for torn-off file handles, so the referential transparency requirements of both the file-using process and the outside world are satisfied.

Network sockets: Sockets for protocols like TCP are not amenable to finalization-free garbage collectors, because the process of closing a socket has non-referentially-transparent IO effects that ought not occur nondeterministically. But a language could expose higher level protocols that are more suitable, for example creating the illusion of monadic persistent connections between processes.

Note that all of these considerations aren't terribly relevant in a runtime like .NET which doesn't have a first-class concept of referential transparency. There, any variable in any object might change at any time because other functions to which you have passed the object could at any time modify any variable in another thread or through reflection. But in an environment with a functional subset or just a means of specifying and verifying limits on the scope of effects of computations, it becomes very important to avoid observable side-effects of garbage collection.

There are alternatives: in Java for example, you should use the finally clause and a close method. C# makes it even easier with IDisposable and the using statement. But, at the end of the day, the library writer cannot rely on its users to always use it optimally. Hence, she must employ finalizers, and suffer at least some performance degradation as a result. The fact that a rare system resource might not be released for the duration of the application is even worse.

But in some cases one wonders whether it's worth the price?

This is the semantics of 'rm' in Unix, you can remove a file opened by another application. The problem is if someone leaks such resources, you sometimes find yourself with an empty disk (du = 0) that is full (df = 0)! Well, it makes sysadmin more challenging.

But, at the end of the day, the library writer cannot rely on its users to always use it optimally.

It's sad when it's due to poor language support. It does not seem very hard to make to enforce at least some cases of usage/release with the type system, e.g. if the API for reading files was like:

 foldfile : (Line -> Result -> Result) -> Result -> Filename -> Result

The open/close can be safely included within one atomic call.

Even some trivial stuff like allowing finalizers only on reference-less objects would make the "freeing C API resource" pattern much safer; and is not incompatible with having a distinct unsafe facility for other things, if needed.