Current ideas

[Austin Seipp]

Hi,

Since LHC's creation, I have been doing a bit of work on it,
mainly cleaning things and replacing things etc. - it's now much
easier to build (with cabal,) has some cleaned up code, and general
improvements over jhc I would say (at this point anyway.)

Here's the current ChangeLog:
http://code.haskell.org/lhc/ChangeLog

Before any sort of announcement (and a version bump,) here are some
things that have been on my mind:

 * There could be various improvements in performance and memory usage
   just about everywhere. I have some initial profiling results from running
   the compiler over 'hello world' here:
   http://thoughtpolice.stringsandints.com/code/lhc-tests/hello-world/

   The files are:
   - lhc.prof & lhc-cc.ps - detailed cost centres - we see about 40%
     *total* time and allocation is spent in E.Binary on two different get
     routines for Data.Binary.
   - lhc-constr.ps & lhc-type.ps - most of the allocation goes to the
     S data type used in the lambda lifter/CPR pass, as well as lazy
     tuples.

   So I think if we can target E.Binary usage, we can possibly cut
   down GC and runtime considerably. We may be holding the GC from 

   Note that these benchmarks were run before I replaced several other
   parts of the code and removed a few things, notably replacing DrIFT
   with derive - I noticed GC went up to about 61% from the average
   58% for DrIFT. I should probably update them.

   (Also, GHC HEAD has had recent improvements to the parallel garbage
   collector, etc. so I would like to see if running lhc on top of it
   would reduce garbage time with -N2 and -threaded.)

 * I think we should continue with jhc's goal of sticking with the latest
   GHC. I see potential in use in quasi-quoting, for perhaps replacing
   the FlagDump, Name and PrimitiveOperators information that was part
   of the autoconf build system. 
   We can easily construct a parser with parsec (or even a
   regex lib; the perl scripts for this are in util/) and go from
   there; this also replaces another external dependency
   and makes cabal life better.

 * The region inference algorithm is currently buggy, and code leaks
   pretty badly if it runs for a while. If you look here:
   http://thoughtpolice.stringsandints.com/code/lhc-tests/bench
   and build, loop and startup work fine, but recursive almost immediately
   starts gobbling up 800mb+ of memory. This is something to be
   addressed for sure.

 * Right now the parser is featureful and works, but we may also
   be able to swap it out to say, haskell-src-exts.

   Pros: way more extensions we can support out of the box, many
         probably pretty easily with some knowledge of E and GRIN.
   Cons: we lose pragma's entirely, and we must effectively put all
         extensions on, all the time.

   Losing pragmas is a problem, but it is a TODO on the
   haskell-src-exts project, and I'm convinced it could be worked in
   there in the interests of making lhc more robust.

   I am also not convinced that losing the ability to turn language
   extensions off is a particularly bad thing either; with
   haskell-src-exts we immediately gain support for a large variety of
   extensions making lhc compatible with a much more vast amount of
   code immediately; although we will have to implement code for
   extensions like associated types, GADTs, etc. etc..

   I think contribuing back to haskell-src-exts would probably be a
   good idea.

 * We definitely need a testsuite - I think a good first suite to
   target and fully compile would be nobench.

 * We should eliminate the last bits of the old build system; I have just
   eliminated cbits as we don't need it, and we need to replace the
   Name, Flag and PrimitiveOperator generation routines, because right
   now they're generically hard-coded in there.

 * There should be something like a LHC commentary. Starting one on
   http://lhc.seize.it seems reasonable.

 * Should find a way to get lhc's base package on hackage so we can do
   'cabal install lhc; cabal install base --lhc' 

These are all of my thoughts, I would like feedback from anybody
willing to contribute to the project. I realize all these things are
something of a significant engineering effort, but these are a few
core things that if put in place could greatly help LHC as a compiler
and haskell programmers.

Austin