#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by hsyl20): Replying to [comment:1 simonpj]:

Why will it make "better integration" with other packages?

Because most other multi-module packages don't put modules directly in the "root namespace". It feels a little bit unusual that GHC modules in an import list don't share a common prefix (especially for utility modules like FastString whose package is not obvious).

I think by "better documentation" you perhaps mean "easier to navigate".

Yes indeed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D3647 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by hsyl20): The discussion about the renaming has started on Phab. I'm copying it here. simonpj: For example, I'd like to remove the IR/ level, and just have Cmm, Core etc. It doesn't pay its way in my view. simonmar: I agree with @simonpj that IR should go away for example. me: Considering the proposed hierarchy, I have been loosely following the old proposal on the wiki (ModuleDependencies/Hierarchical) but adapted it. I have iterated quite a few times and indeed I started without the IR level but it felt wrong for GHC.Haskell (isn't GHC all about Haskell?) and GHC.Core ("core" is misleading and I wouldn't think it is an IR if I wouldn't already know it is). Moreover I didn't want to pollute too much the top-level. In general I have tried to make module names meaningful and unambiguous, even to someone that is first exposed to them. For instance, just by looking at the outline (e.g., see current Haddock on http://hsyl20.fr/ghc_doc/), even if we don't know what FloatOut is, we know it's a transformation on Core IR. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by mpickering): I think the benefits of this are very marginal and the costs quite high for package maintainers. In general I don't like long module names but that is also a matter of preference. It is usual (at least in my projects) to import modules from GHC as qualified which avoids the problem with clashing module names. To take your example of `FloatOut`, it's already in the folder called `simplCore`. The modules are organised in a directory hierarchy just not a namespace hierarchy. It seems the benefit is for browsing documentation in haddock, but it is already hard to use haddock with GHC as not that many functions have haddock comments and you need to read the Notes in order to understand everything. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by bgamari): On the matter of the concrete renaming, I would say that unnecessary renaming of GHC's traditional nomenclature should be avoided. That is, renaming the desugarer to `HaskellToCore` is in my opinion going to cause far more harm than good. These names are scattered throughout commit messages, documentation, comments, and the wiki and it's not practical to rename them all. While it may be true that the function of the "desugarer" isn't immediately clear to newcomers, I would argue that this nomenclature is a tiny bit to learn relative to the rest of GHC, and that inconsistent naming will make things even harder. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by hsyl20): I have tried Cabal's feature to rename modules (thanks @hvr): https://github.com/hsyl20/ghc-api-compat With a package of this kind, the transition should be smoother for package maintainers. The benefits may seem small because it's only module renaming for now. But it's a preliminary step to help fixing other issues.

but it is already hard to use haddock with GHC as not that many functions have haddock comments and you need to read the Notes in order to understand everything.

I would say that we should fix haddock comments in GHC. In addition maybe we could make haddock export Notes in the generated documentation.

Long standing patches and branches need to be re-based and imports renamed. While I appreciate that it's a one time cost, it's a very painful one.

Agreed. However it may not be that painful. I've already rebased the patch (e.g., on "Trees that grow" and on the patch introducing the FileCleanup module) and it was easy.

the split between ghc/ghci and compiler/GHC.Interactive seems weird.

It's just the split between ghc-the-program and ghc-the-library. (I have generated some graphs: http://hsyl20.fr/ghc_module_deps/). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by bgamari): hsyl20, we discussed this in the call yesterday and it seems that we generally agree that this sort of restructuring is something that we want to do. However, we would really like to have a discussion of the concrete restructuring. Currently the best means we have for collaboratively discussing a document like this is the [[https://github.com/ghc-proposals /ghc-proposals|GHC Proposal process]]. Do you think you could write up a proposal giving your proposed restructuring and describing how we plan to mitigate the adverse effects for API users? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3647 Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by hsyl20): The proposal: https://github.com/ghc-proposals/ghc-proposals/pull/57 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13009#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler