GHC source code improvement ideas

[Neil Mitchell]

Hi

Yhc did a few of these things, and our experiences were:

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

If it is that simple, yes. Certainly Yhc uses "super-monads" which
made this a bit painful. You should probably step this by getting it
to the stage where thenXX = >>=, then only flipping to do notation
once the things are already monads.

>   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

I still don't particularly like applicative, it is a bit confusing to
me. If you moved to using the Uniplate library, you could then write:

descendM dsHsType

Shoter, more concise, and probably works for more cases than just
HsFunTy - eliminating even more code. I suspect moving to Uniplate
would give GHC massive benefits.

>   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.

We did this in Yhc, and it was really useful just to group files into
the same directory.

Thanks

Neil