Friday, April 10, 2009

A new beginning.

The LHC project has finally resumed development after a few weeks of inactivity. Things have taken big steps in a new direction, however, and nearly everything except the name has changed.
We're no longer a fork of JHC. Maintaining a complete Haskell front-end was too much of a hassle, especially considering we're only interested in optimization on the GRIN level. For this reason, LHC has reinvented itself as an alternative backend to the Glorious Glasgow Haskell Compiler.

The lack of testability was a major problem in the previous version of LHC but hopefully we've learned from our mistakes. The new development efforts will be structured around a decremental reliance on a GRIN evaluator. In other words, we want to run the full testsuite between each and every significant code transformation. That no transformation should change the external behaviour of a GRIN program is a very simple invariant.

The current toolchain looks as following:

david@desktop:basic$ cat Args.hs
import System

main :: IO ()
main = do
as <- getArgs
mapM_ putStrLn as
david@desktop:basic$ ghc -fforce-recomp -O2 -fext-core -c Args.hs
david@desktop:basic$ lhc compile Args.hcr > Args.lhc
david@desktop:basic$ ./Args.lhc One Two Three
One
Two
Three


The contents of 'Args.lhc' is unoptimized GRIN code. It is not by any means efficient or fast but it serves its purpose.

Development will now focus on creating GRIN transformations that reduces the need for the RTS (our GRIN evaluator serves as the RTS).

8 comments:

  1. This sounds like a very smart move -- I'll be following the development of LHC closely. Module-at-a-time compilation is holding GHC back.

    ReplyDelete
  2. What lessons are you taking from JHC, and is any code at all shared with the projects now? What happens with the runtime?

    ReplyDelete
  3. If there /is/ no shared code with JHC, would you consider licensing under a BSD rather than GPL license? I understand if you don't wish to, but this is a concern for me because there are some legal restrictions on my contributing to projects with a GPL style license.

    ReplyDelete
  4. Max Bolingbroke:
    That was the first thing I did. I'm no fan of GPL myself. (:

    ReplyDelete
  5. More information please! There hasn't been any activity on the mailing list. I may not be directly involved, but I would like to track what's going on.

    Alternatively, you can share more about what changed on the blog. But please do keep your rapt audience informed. :)

    ReplyDelete
  6. dons:
    Working on JHC and GHC has taught me how easy it is for developers to fall back on "untyped" programming. As projects grow, people rely less and less on the type-system. Refactorings in both projects can easily end up in well-typed programs that end in run-time failure.
    While I can see that proving correctness can be arduous, proving completeness should be mandatory.

    One example would be JHC's core->grin transformation. This transformation requires that all lambdas have been removed from the core. JHC relies on other parts of the program to be aware of this fact and it simply throws an error if the input wasn't what it expected.
    In LHC, I made the transformation of external core to grin using an intermediate step. First I translate to SimpleCore (a subset of Core) and show that ALL core has a valid SimpleCore representation. Then I translate SimpleCore to Grin and show that ALL SimpleCore has a valid GRIN representation. In this way I'm certain all core has a valid GRIN representation and no amount of refactoring can affect this.


    No code is shared between JHC and LHC anymore. LHC's codebase is now under the BSD3 license.

    I'm not sure what you mean by the runtime.

    ReplyDelete
  7. On:

    http://www.cs.uu.nl/wiki/bin/view/Ehc/EhcUserDocumentation

    we are documenting the current status compiler which uses a GRIN based back-end too. Its home page is to be found at:

    http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome

    Doaitse Swierstra

    ReplyDelete