Thursday, August 18, 2011

Ending GSoC

As the firm pencils down date for Google Summer of Code is coming up Monday, I figure I'd better make sure everyone understands what I've done and how to use it.
  • GhcOptions Record
  • This record has fields for every GHC option used by cabal. It replaces the ad hoc lists of strings that were used previously. GhcOptions is also a Monoid instance, so one can mapped more specific options onto basic ones. To allow this instance, lots of fields are wrapped in All, Any, First, and Last constructors, which can be kind of a pain when filling the fields manually, but it's a small price to pay for composability.
  • Repl Function
  • This addition to the Cabal API will start an interpreter session. By default, it will load all files from the library component of a package. If the user passes specific files, the function will try to build the component that contains these files, failing if no such component can be found or if multiple components contain the files. If the user wants to load some specific component, this can be specified by the --component flag. Like other functions in the cabal API, there are number of hooks that the user can specify to change default interpretation behavior: preRepl, replHook, and postRepl. The names kind of speak for themselves.
  • GHCi Support
  • The repl function eventually calls an interpret function defined individually for each compiler. Currently, the only compiler with interpretation defined is GHC. GHC's interpret implimentation also defines a series of macros that overload the standard :load and :reload interpreter commands to call cabal repl --enable-reload on the specified component before loading so as to do whatever preprocessing is necessary.
  • Other Changes to the Cabal API
  • Because GHC's interpret function calls the cabal-install tool, I had to add cabal to the list of known programs (including ar, ghc, ghc-pkg, etc). Also, because interpretation does not necessarily require building every single package, the topologically sorted build order list used in building is no longer sufficient. I've added a compBuildMap field to LocalBuildInfo which maps components to their topologically sorted list of dependencies.
  • Cabal Repl
  • The cabal-install tool now has an repl command:
      Usage: cabal repl [FILENAME] [FLAGS]
        Enable file reloading from within an interpreter.
        Disable file reloading from within an interpreter.
        The component of the cabal package to interpret
            cabal repl
          Only library component in the package
            cabal repl Examples/Foo.hs
          Specific file
            cabal repl Bar.hs --component=myexe
          File from specific component
            cabal repl --component=library
          Library contained in the package
        The usual flags apply as well, of course, and the --enable-reload option isn't really meant for anyone except cabal itself to use when reloading packages.

      Oh yeah. Here's the code, and here is the haddock stuff.


      1. Way to go - this looks really nice.

        Are there any roadblocks for getting the changes accepted in Cabal?

      2. Just so I understand what you mean in the GHCi support: if I load up a package like text, will both Data.Text and Data.Text.Lazy (with all the namespace collisions) be loaded?

      3. Nice stuff, thanks! Hope it gets applied.

      4. You only have a few hours to actually submit your self review for the summer of code if you want them to actually send you money.