Ten Cache Misses

Crushing Haskell like a Tin Can

Cabal: a Haskell eDSL?

While I’m working on more radical ideas about Hackage and Cabal, I thought I’d stick out a couple more palatable ones now.

Cabal (almost always?) links an executable whenever cabal install <some package> is run. Combined with a slow linker such as OSX’s… and well, it’s slow. The generated application is almost always a shim around the (compiled) Cabal library, so linker step can probably be removed entirely. The general design permits the installer to select which version of the Cabal library to use, cabal-install just provides the bootstrap. I think this could be done done with runhaskell or runghc instead.

When porting our build system from cabal-waf to shake-install I decided to carry forward WAF’s use of the host language (WAF uses Python) as the Makefile language. Haskell seems like a natural way to describe the build hierarchy for Haskell projects, though shake-install reads dependencies from .cabal files. Could this idea be further extended to replace Cabal’s language entirely with an eDSL? Link in GHC as an interpreter and you’ve got a fast Haskell build system.

Monadic, applicative or monoidal. This is just an idea without implementation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import Cabal

-- equivalent of 'Main :: IO ()' for Cabal installers
cabal :: Cabal Package
cabal = package "sample" $ do
  language Haskell2010
  license BSD3

  library "demo" $ do
    depends $ do
      "base"         (==? any)
      "stm"          (>=? "2.3")
      "transformers" ((>=? "1.0") <> (<=? "2.0"))

    options GHC $ do
      "-Wall"
      "-fno-warn-foo"

    modules $ do
      exposed "MyPackage.MyExposedModule"
      hidden  "MyPackage.MyHiddenModule"

Comments