Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Haskell Can Now Do Strict Evaluation by Default

Haskell Can Now Do Strict Evaluation by Default


A new Strict language extension to Haskell aims to make it easier to use Haskell for code that is meant to be mostly strict, i.e., evaluated in a non-lazy manner. The feature was recently merged into GHC’s git HEAD and will be included in GHC’s next release.

The -XStrict and -XStrictData pragmas will switch Haskell behaviour on a per-module basis so functions, data types, and bindings are evaluated strictly and not lazily. -XStrictData is a subset of -XStrict and only affects bindings. Thus, when -XStrict is specified,

data T = C a
f x = ...
let x = ...

is actually interpreted as if it were:

data T = C !a
f !x = ...
let !x

Lazy-evaluation can be reinstated on a case-by-case basis by prepending ~ to variable names. So, these pragmas sort of reverse Haskell’s default behaviour, where evaluation is lazy and can be made strict by using ! in front of names.

As Adam Sandberg Ericsson, implementor of the strict pragmas, noted, this feature will not turn Haskell into a strict language, rather it provides a means to write better looking code when strict evaluation is required. He also adds that the patch comprises 500 lines of code which mostly have to do with extending Haskell so it allows strict bindings to be recursive and polymorphic and to a lesser extent with inserting strictness annotations where required.

Johan Tibell, Google engineer under whose supervision Sandberg Ericsson implemented the strict feature, further clarified the benefits that it will provide, namely reducing syntactic noise and chances of errors when using the bang in Haskell code that should be mostly strict, and understanding how changing Haskell’s default behaviour may affect performance. Tibell also remarks that adopting StrictData will likely bring only modest change to a code base that is already using strict constructor fields. On the other hand, adopting Strict will presumably imply lots of changes in existing code bases, so it should be taken with more care.

Rate this Article