What is LHC?

It might be difficult to get a sense of how feature-complete LHC is just by looking at the wiki and the mailing list. In this post I will try to answer the common questions of what LHC supports and where LHC is going.

Let me start by introducing LHC itself. The LHC Haskell Compiler (LHC for short) was born out of JHC on a cold Tuesday morning, November 18th, 2008. Her birth was necessitated by a conflict of opinion between John Meacham (the author of JHC) and myself. We simply couldn't agree on which build system would be the most appropriate: make or cabal. Since then we've made many changes that are unlikely to be merged back into JHC.

As of this writing, LHC differs from JHC in the following ways:

• Cabalized build system instead of Make.
  
• Extensive use of Haskell libraries. We have six more dependencies than JHC.
• We use 'derive' instead of the unwieldy 'DrIFT' package. This, among other things, makes it possible to generate HPC information.
• We support both GHC-6.8.x and GHC-6.10.x.
• We're available on Hackage.
• We've eliminated some usage of unsafe IO. On a project of this magnitude, getting segfaults instead of type-errors isn't acceptable.
• We're very liberal in granting commit access. It's easier to undo bad patches than to make people contribute.

Although we are not JHC, we are still similar enough to share many of the same disorders. Most importantly, we don't have support for exceptions, garbage collection or proper type-classes.

The issues with type-classes is purely due to bugs in our code, and hopefully we can resolve them without too much headache. It should be noted that since Monad is a type-class, there are very few programs that LHC can compile at this stage.

Exceptions and garbage collection are more fundamental problems, though. We simply cannot implement those feature efficiently in C. Using C-- is an obvious solution but unfortunately there are no usable C-- compilers. Using LLVM[1] is out of the question for the same reasons as C. We will probably end up writing our own native code generator.

All in all, our future plans are like this:

1. Disable features until we can correctly compile Haskell98 programs.
2. Extend our testsuite to cover most of the codebase.
   
3. Address performance issues. We are about 5-10 times slower than GHC and there are no fundamental reasons for this.
4. Write a code generator that supports exceptions and garbage collection.
   

[1]: On the surface it looks like LLVM has decent support for exceptions and garbage collecting. However, the documentation shows that it is essentially no better than in C.