Type enforced "strict/imperitive" subset/version of Haskell

Question

I quite like Haskell, however one of the main things that concerns me about Haskell the difficulty in reasoning about space usage. Basically the possibility of thunks and recursion seem to make some tricky situations where it seems one has to be very careful by adding the correct strictness lest the program run out of memory on particular inputs.

What I like about C/C++ is that I can quickly be fairly certain about the upper bounds of a programs space usage, in particular if one avoids recursion. The variables are clear to see.

What I was wondering is if there's a way to create a typesafe "imperative" subset of Haskell, which doesn't have thunks, and is strict.

I understand Data.STRef gives mutable cells, but as far as I understand these cells themselves are still lazy and can contain thunks. I was thinking to force the data in such cells to be strict, but I'm unsure how to do this in a manner enforced by the type system.

I was thinking something like a "Strict Monad" but perhaps that isn't the correct form to do this in.

Answer 1

I'm fairly sure it would be next to impossible to implement this in Haskell, which really assumes laziness by default. For example, there are functions all through the standard library which would be useless in a strict language because they are in fact guaranteed not to terminate if you request their entire output. So if you had a "strict subset" of Haskell, it would be difficult to interoperate with any other Haskell code, and you'd effectively be programming in another language anyway.

Also, I think you're looking in the wrong place by thinking about monads. Data.STRef indeed has nothing to do with avoiding thunks and laziness. In fact what you want (strictness) has nothing to do with being imperative, and you don't need mutability or monads to get it. There are programming languages which are just as pure as Haskell, but strict everywhere. One I have worked with is Mercury, for example.

Answer 2

You might be interested in reading about BangPatterns language extension and Unboxed types/operations. But you also should know the fact any function will always have meaning of boxed type. That's responsibility of optimization to eliminate any ref-kind values by compiling code according to "bangs" and other stuff into functions.