Max Bolingbroke 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}
I'm all for trying to classify things and make a sensible hierarchy, as
long as we accept that the hierarchy doesn't convey much about
dependencies, it only helps to keep related functionality together.
but I think the above examples are wrong. A Name is as much a binder as an
Id. This is an example of what Simon raised: we'll probably want to think
about the hierarchy quite a bit first. Sure we could just capitalise all
the directory names and get GHC.BasicTypes.Id for example, but that's
almost certainly not where we want to end up. There'd be a further shakeup
later on when we figure out what the hierarchy really should be. So I
suggest we think about the hierarchy and make the change in one big step
after the 6.10 release.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
