Hi all,
In yesterday's #ghc meeting we discussed whether the GHC library should
use hierarchical module names. We haven't reached any decisions yet, so
please let us know what you think now!
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
* While there are some disadvantages, e.g. you need to type "GHC." a
lot, there is nothing special about GHC that makes it worse than for
any other library. Or to put it another way, if it is too inconvenient
for GHC to use hierarchical libraries then why should we expect any
other libraries to use them? If we believe that it is "too
inconvenient" then we should fix that regardless of what GHC does.
* It would allow us to clean up some poor-man's-hierarchy module names,
e.g. Tc*.lhs
* We could expose the GHC package by default (not a huge win, as Cabal
packages are unaffected by exposedness; it does make a difference to
ghci, though)
* The GHC package docs could go into the main documentation index
* It allows users of the GHC API to use names like Util for their own
modules.
The idea would be that, for example, the TcExpr module in the typecheck
directory would become the GHC.Typecheck.Expr module.
This overlaps uncomfortably with the GHC.* modules in the base package.
In the short term we'd probably rename these to GHC.Lib.*, and in the
longer term perhaps they could become Prim.* in ghc-foo packages.
Next there is the question of when to make the move. One option is just
after the 6.10 branch is forked. However, this has the problem that
bug fix merges may conflict for two reasons:
* Anything that adds or removes an import will fail
* I don't have a good feel for how well git will cope with all the file
moves, but if it gets confused then any merge can fail
The other option is to make the change before the split (but ideally
after the various branches destined for 6.10 have been merged).
Finally there is the question of backwards compatibility.
The first possibility is to have, e.g., a TcExpr module in the ghc
package which just reexports GHC.Typecheck.Expr. If we did this then we
still couldn't expose the ghc package yet, and users couldn't use module
names like Util.
The second possibility is to do the same, but put the re-exporting
modules in a ghc-compat package. This wouldn't be a compat package in
the same sense as the base3-compat package, as it wouldn't attempt to
provide the 6.8 GHC API.
The third possibility is to do nothing. Thomas Schilling said:
if my GHC API changes go in, virtually every API client will break
so we could just rename modules at the same time
(the hope is for his patches to go into 6.10, as I understand it).
Thanks
Ian
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
