[rollo]

I'm a Haskell newbie, and when I test a program and it shows a laziness-related space leak, I just put strictness annotations on the parameters I suspect of generating large unevaluated thunks. This has always made the issue go away so far.

[catnaroek]

But, would you not agree that it would be really nice to have separate strict vs. lazy types? It would bloat the syntax a little bit (e.g., Coq needs separate Inductive vs. CoInductive, Fixpoint vs. CoFixpoint keywords) but the benefits in terms of not having to find space leaks via debugging and profiling would be enormous.

[trobertson]

There are several libraries that do distinguish between strict and lazy types. containers [1], for example, separates strict Maps and IntMaps.

That said, introducing new syntax to annotate strictness is far more troublesome than separating strict types from lazy types at the module level, where switching between the two is a comment away:

       import qualified Data.Map        as M
    -- import qualified Data.Map.Strict as M

Introducing syntax would make switching between the two far more painful.

[1]: https://hackage.haskell.org/package/containers

[catnaroek]

When I say sometimes I need strictness, I really mean it. (Without ugly hacks like deepseq, that is, because I am fundamentalistically opposed to hacks.) WHNF does not quite cut it. This is not to say that I dislike laziness. I want first-class support for both strictness and laziness.

When you come to think about it, a separation of strict types and lazy types makes perfect sense. For example, I want to foldl on lists (strict) but foldr on streams (lazy). I do not want to accidentally use the wrong operation on the wrong type. it is tiny details like these which make a type system helpful for guaranteeing correctness and improving performance.

So, if strictness and laziness are both useful and distinct from one another, why not provide both as core language constructs? Why do languages always have to be biased towards one of them?