(New page: =haskell-suite= ''Niklas Broberg'' For many years now, Haskell has become increasingly synonymous with its implementation in GHC. While GHC is an incredible and much beloved compiler, th...)
Latest revision as of 13:44, 17 December 2012
For many years now, Haskell has become increasingly synonymous with its implementation in GHC. While GHC is an incredible and much beloved compiler, this situation is still unfortunate. GHC is a highly optimizing compiler, and the implementation choices are made thereafter. In particular, the possibility to use GHC compiler functionality from third-party code is added as an afterthought, in the ghc-mod library. Pointedly, the library interface reflect the structure of GHC more than the needs of client library writers.
My haskell-src-exts library has become the de facto library for manipulating Haskell source code. Its interface is designed entirely with its clients in mind, and it has been widely adopted in the Haskell community. But syntactic manipulation only gets you so far, and many are the voices that decry the lack of accompanying semantic abilities, and work has started on delivering that.
In my talk I will give an overview of the existing work on haskell-src-exts (syntax), haskell-name-exts (name resolution) and haskell-type-exts (type checking). I will also present my grand vision for a complete haskell-suite: a modular set of libraries covering all that is Haskell, forming a reference implementation.