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.
+1
I tried to plot GHC's dependency graph but it just became a grey/black
cloud. A hierarchical module space could clean things up a bit.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
