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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
