Tjena! After some dependency analysis and a (more or less) careful inspection of the GHC source code, I put together a proposal for GHC's new hierarchical layout:
http://hackage.haskell.org/trac/ghc/wiki/ModuleDependencies/Hierarchical FWIW, here's the current dependency graph of the top-level parts of GHC (excluding utils) http://hackage.haskell.org/trac/ghc/wiki/ModuleDependencies#High-levelDependencyGraph There are several "?" indicating that I was not entirely convinced with the choice (some are missing, too). Some thoughts: - I didn't consider long names to be a bad thing. We tend to use whole module imports and an import takes up at least one line, anyway. - I put Name/OccName/Id into GHC.Naming.* but perhaps putting it under GHC.Types.Naming.* or even GHC.Types.* would be better. - Some cross-cutting concerns like the strictness analysis and profiling ended up under GHC.Core/STG and are no longer clearly marked. I don't know how useful that distinction was. - I like the idea of having a GHC.Core module that re-exports most of the things that one might use when writing a plugin or just taking core as an output. I.e., (what is now) CoreSyn, CoreTidy, CoreUtils, and some more - Some module descriptions are not very helpful. - I put most of the utils under GHC.Utils but perhaps some of them might be worthy a top-level name. E.g. Data.FastString or Data.Bag. - I didn't touch the Cmm / CodeGen / NativeGen files since I expect some changes when the new code generator branch is merged. For the sake of discussion I think it's probably best to copy'n'paste parts from the wiki page into a mail and comment on it here on the list. In general wikis tend to be less useful for discussion, rather than to summarise a discussion's result. Cheers, Thomas _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
