On Aug 28, 2008, at 12:39 PM, Thomas Schilling wrote:
On Thu, Aug 28, 2008 at 7:46 PM, Max Bolingbroke
<[EMAIL PROTECTED]> wrote:
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.
I also say +1.
When I was doing work on External Core, I regularly wished that GHC
used hierarchical modules.
Aaron
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
