[web-devel] GSoC project idea: haskell-type-exts

Niklas Broberg niklas.broberg at gmail.com
Wed Mar 28 12:03:32 CEST 2012


See ticket here: http://hackage.haskell.org/trac/summer-of-code/ticket/1620

== What? ==

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.

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.

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.

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.

So - what we need is a type checker that works on the HSE AST:
haskell-type-exts!


== How? ==

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.

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.

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.

There are also some design issues to get right (e.g. using pure
substitution vs efficient mutable variables).

I (Niklas Broberg) am more than willing to mentor this project.


== Further reading: ==
[1] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical
type inference for arbitrary-rank types.
[2] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann.
OutsideIn(X) – Modular type inference with local assumptions
[3] M. P. Jones. Typing Haskell in Haskell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20120328/afc5f296/attachment.htm>


More information about the web-devel mailing list