[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?