<div>See ticket here: <a href="http://hackage.haskell.org/trac/summer-of-code/ticket/1620">http://hackage.haskell.org/trac/summer-of-code/ticket/1620</a></div><div><br></div><div>== What? ==<br></div><br> The haskell-src-exts library (HSE) is very popular for manipulating Haskell source code in a wide range of scenarios, such as (syntactic) preprocessors (e.g. hsx), syntax highlighting, refactoring and code inspection (e.g. hlint), etc. <br>
<br> A commonly sought feature, that would enable a multitude of new and improved scenarios, is the ability to type-check the code, and annotate the AST with type information. Type-driven refactoring, type-aware code inspection, type-based preprocessing, ... Lots of pure awesomeness lies in that direction. <br>
<br> Sadly, HSE has no type-checking abilities. For those who seek such, we are forced to point in the direction of the dark cave that is the GHC API. While GHC is an utterly awesome compiler, there are several reasons why this is not an ideal situation. First, GHC was designed and built for optimization, which means that even the early stages of the compilation pipeline contain features that cater to later optimization, but that are (at best) unnecessary for a front-end tool. Second, the API into GHC internals is defined as an afterthought. Some good work has been done to make it somewhat palatable, but it remains a fact that GHC's primary purpose is not to be a library for integration in tools, and this shows. Overall, depending on GHC when all you want is front-end capabilities like parsing and typechecking, is really like using the proverbial sledge hammer. <br>
<br> Also, at the meta level, GHC deserves "competition". Right now GHC is de facto the only implementation of Haskell, and as such it more or less defines the progress of Haskell. Too often this leads to overly pragmatic choices, which lead to inconsistencies and headaches for tool programmers. Having a separate, stand-alone front end library would help set higher standards. <br>
<br> So - what we need is a type checker that works on the HSE AST: haskell-type-exts! <br><div><br></div><div><br></div><div>== How? ==<br></div><br> I now hear you think: "This is too much, an enormous project, surely it can't be done as a GSoC project?" Sure it can! By walking in the footsteps of giants, and following GHC's approach. This can be achieved by closely observing the documentation provided by [1] and [2], with a bit of [3] thrown into the mix. <br>
<br> I already have a basic library that provides most of the core framework necessary to cover extensions, but at this time it's mostly just scaffolding. It needs a lot of love, to provide cover for all the various available extensions, but I'm confident it can be done satisfactorily as a GSoC project. <br>
<br> Still, it would be reasonable to modularize the task. Certain features are more crucial than others to support, simply because they have a more profound impact on the overall type-checking. Higher-rank types, GADTs and type families (and fundeps) are likely the most important ones to get right. <br>
<br> There are also some design issues to get right (e.g. using pure substitution vs efficient mutable variables). <br><br> I (Niklas Broberg) am more than willing to mentor this project. <br><div><br></div><div><br></div>
<div>== Further reading: ==<br></div><div>[1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. <br></div>[2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions <br>
[3] M. P. Jones. Typing Haskell in Haskell<br>