GHC source code improvement ideas

[Twan van Laarhoven]

Hello GHC people,

I was trying my hand at some GHC hacking, and I couldn't help but notice 
that much of the code looks (IMHO) horrible. There are some things that look 
as if they haven't been touched since the Haskell 1.3 days. The most 
striking is the use of `thenXX` instead of do notation.

I was thinking of cleaning up some of this. In particular:

  1a. Use do notation where possible instead of `thenXX`.

  1b. Even better, use Applicative where possible. For example

         ds_type (HsFunTy ty1 ty2)
           = dsHsType ty1			`thenM` \ tau_ty1 ->
             dsHsType ty2			`thenM` \ tau_ty2 ->
             returnM (mkFunTy tau_ty1 tau_ty2)

      Could be rewritten as

         ds_type (HsFunTy ty1 ty2)
           = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2

  2. Investigate the need for all these mappM functions. To quote the 
source: "Standard combinators, but specialised for this monad (for 
efficiency)". Wouldn't a SPECIALIZE pragma work just as well?

  3. In general, use standard functions when they are available. Currently 
GHC has its own sort function and its own versions of FiniteMap/Data.Map and 
Text.PrettyPrint. Using standard functions/data structures will a) make GHC 
smaller and therefore easier to maintain, and b) will make the code easier 
to understand for someone who knows the standard library.

  4. A more radical change would be introducing hierarchical modules. This 
could be just a matter of renaming the directories to start with an upper 
case character and changing the import declarations. This gives module names 
like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be 
renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would 
be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the 
GHC api.


How do the GHC developers feel about this? Would such paches be gladly 
excepted? Or will they be directly forwarded to the bit bucket?

Twan