Are all languages leaky?

Dolio wrote an excellent comment on space leaks for the previous post. I’ve read posts on haskell-cafe before that mentions the concept but I’ve never bothered to ask. Thanks for clarifying the term!

Dolio’s comment made me think of something I heard during a lecture on OO at university, with the risk of paraphrasing slightly:

It helps a lot to know how a C compiler works while programming C.

In my mind this means that the language is “leaky” in a similar sense to how Joel’s law of leaky abstractions. I suppose a programming language is little more than an abstraction of the machine underneath or, in the case of most languages, of the compiler/interpreter of the language.

Now of course I’m left wondering if “leakiness” can be measured, can languages be ordered based on it? Maybe there are two dimensions to “leakiness”, how early you need knowledge of the layer below and how deep knowledge that knowledge has to be. My gut tells me you can’t program in C for very long without needing some compiler knowledge but I’m not sure just how deep that knowledge needs to be. My gut also tells me I can blissfully hack along in Haskell for quite a while before needing to know how things like laziness actually works, and again I don’t know if the knowledge needs to be deep or not ((My problem is really that I feel I know a fair bit about how compilers and interpreters work for imperative languages like C, while I’m new to lazy functional languages like Haskell.)).

Yes, I’ve been in a somewhat philosophical mood lately (some would say it’s a procrastinating mood :) ).

Russell O'Connor

I’m not sure that Haskell abstraction is exactly leaky in this way. The Haskell language does not give operational semantics (giving denotational semantics instead), and hence does not provide any time/space guarantees (If I understand correctly). Therefore, any time you write a Haskell program with the intent of getting a certain space or time complexity, you are relying on compiler specific behaviour.


Russel, I think I see what you mean. In C the leakiness happens already when trying to achieve basic functionality (e.g. I need to know that a local variable is allocated on the stack, so returning a pointer to a local array is problematic) while leakiness in Haskell doesn’t happen until you try to achieve functionality with certain characteristics (e.g an algorithm executing in linear time or space). I guess this is an argument in favour of non-lazy languages in many cases, especially on embedded devices.


Interesting. I think the thing is that C is (intentionally) a thin layer of abstraction over the machine: C abstractions map to their implementations in a very simple way. So, while it’s very useful to know what your abstractions will become translated to, it’s not especially onerous.

Haskell’s a much thicker abstraction layer. I’ve got myself into some horrible messes with laziness and space leaks: in fact, pretty much every time I try to write Haskell code to work with large input or to do long calculations! At this point, you really need to know a bit about how the garbage collector works.

Leave a comment