Outside of the compiler itself: A JHC equivalent to ghc-pkg would be nice. That, I'd imagine, would require some Cabal library integration. As for the compiler: 0. The performance of the jhc compiler is sometimes downright slow. Given your description of how JHC works it makes sense why the compile times can be long. Looking into optimizing this would be nice. 1. Additional documentation of the compiler source. This isn't much of a problem given the code is quite clear. 2. Improved garbage collector? This might just be a documentation issue. The documentation states the region-based garbage collector leaks memory. And the configure script hints at being able to use a standard Boehm garbage collector library. Does the region based garbage collector still have issues? When should one be used over the other? 3. Direct code generator instead of relying on the C compiler. In addition to opening up some generated code optimization possibilities this may tie in with #0 above. Perhaps some compiler performance optimizations are only possible with a native code generator? I would like to get involved in JHC more and see me mostly able to contribute to #0 and #1. Specifically I plan on attacking #0 and documenting everything I read in the source along the way. Cheers, -Corey O'Connor On Tue, Jun 23, 2009 at 4:55 PM, John Meacham<john@repetae.net> wrote:
I figured I'd ask all of you, what do you think the most important thing to work on in jhc right now is?
I hit a major milestone by being able to compile a whole host of packages unchanged.
Jhc alreadly works admirably as a cross compiler and generates pretty speedy code. It would be very easy for me to get lost in coming up with new, wacky optimizations. So, what do you want to see before that happens?
John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc