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).
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.
ReplyDeleteWhat lessons are you taking from JHC, and is any code at all shared with the projects now? What happens with the runtime?
ReplyDeleteIf 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.
ReplyDeleteMax Bolingbroke:
ReplyDeleteThat was the first thing I did. I'm no fan of GPL myself. (:
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.
ReplyDeleteAlternatively, you can share more about what changed on the blog. But please do keep your rapt audience informed. :)
dons:
ReplyDeleteWorking 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.
On:
ReplyDeletehttp://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
the red hands look sharp and charismatically spooky against the black.
ReplyDeletehttp://www.watchestoo.com
SWISS ROLEX DAYTONA 116509A
SWISS ROLEX DAYTONA 116509E
SWISS ROLEX DAYTONA 116523C
SWISS ROLEX EXPLORER II 16570A
SWISS ROLEX EXPLORER II 16570C
SWISS ROLEX GMT-MASTER