A software engineer website

Haskell: imports vs exports

Gautier DI FOLCO February 14, 2024 [Software engineering] #software engineering #design #haskell

Haskell modules are defined with:

When I build a module, I think in terms of interface, that's why I enumerate the exports:

module Naturals
  ( Nat,

It has several benefits:

This helps also to create smart-constructors, a common idiom which uncouple data-representation and data-construction.

For example, Nat does not expose the constructor in our example, but mkNat should be used as such:

newtype Nat
  = Nat { toInteger :: Integer}
  deriving newtype (Eq, Ord, Show)

mkNat :: Integer -> Maybe Nat
mkNat x =
  if x >= 0
    then Just $ Nat x
    else Nothing

So mkNat enforces Nat invariant, letting us also the freedom to rework underlying constructors without changing consumers.

On another hand, I tend to let imports implicit (unless there are conflicts, or for clarity, I qualify them for this scenario):

-- Instead of
import Data.ByteString (pack)
import Data.Text (unpack)
-- I use
import qualified Data.ByteString as ByteString
import qualified Data.Text as Text

Which reduces maintenance and diffs.

The rational being that implementations (should) change more frequently than interfaces.