2008/8/28 Ian Lynagh <[EMAIL PROTECTED]>:
> The arguments for moving to hierarchical module names were:
>
> * it makes finding modules much easier for people new to the code
> (although tools can help here). For example, Neil Mitchell said:
> <ndm> Yhc moved to heirarchical module names, and it was a fantastic
> decision
> <ndm> it makes finding modules much easier for people new to the code,
> it took me a while to do so with GHC, finding where an import
> corresponds to
> <ndm> As a beginner, starting to explore the GHC source,
> i'm strongly for it
I second Neil on this: speaking as someone who recently learned his
way around the GHC codebase I always felt that having additional
structure to the module names would have helped me understand the
shape of the compiler. I'd also really like to see structure over and
above just e.g. creating a GHC.BasicTypes namespace and putting
everything in basicTypes into it. Some example namespaces that it
might make sense to introduce are:
GHC.Naming.{Name, NameEnv, NameSet, OccName, RdrName, Module}
GHC.Binders.{Id, IdInfo, MkId, Var, VarEnv, VarSet}
We can also provide convenience modules that reexport names from the
modules below them in the hierarchy. A good example here is a
GHC.Binders module that would export all of the Id/Var stuff, which is
typically what you /really/ mean to import when you say "import Var"
or "import Id". Use of this technique (in moderation) has the
potential to shorten up our import lists in various parts of the
compiler.
Another nice benefit of this scheme, which I don't think you
mentioned, is that it's easier to see when we have silly dependencies
between parts of the compiler since it is manifest in the source code
which functional unit (~ module namespace) you are importing stuff
from.
Max
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
