Architecture

[LeanderK]

I don't feel confident building the GHCi integration right now, haskforce is a bit of an jungle. I am trying to document the classes, but its not easy. To really build a clean, simple GHCi module, we need modularise things. There are currently 20 packages and a few classes in src.haskforce and its really hard to understand the relationships between them. For example cabal is partly modularised (there is a cabal-package), but the actions are in actions.cabal and there are some classes like CabalExecutor in the utils package. But other functionality, like ghc-modi, is distributed everywhere. I would propose the following architecture:

1. system (common functionality/interfaces belongs here)
2. haskell (parser, syntax highlighting etc.)
3. tools (every tool we use and communicate with)
   1. cabal
   2. ghc-modi
   3. ghci (well, in the future)
   4. stack
   5. hindent
   6. ...

i think it would make haskforce simpler, because everything that belongs together is in one (or has one parent-) package. Also developing clean interfaces (maybe even documenting them!) would make feature-development simpler and more independent.

[LeanderK]

i just hacked a bit around and think its doable. Refactoring ghc-modi will be hard though

[carymrobbins]

Yeah, the packages can certainly be organized a bit better.

Although, regarding GHCi integration, not much needs to change. Recall the discussion in issue #289. We just need to provide implementations for the appropriate interfaces/traits. Most of the infrastructure is already in place.

[LeanderK]

i know its possible in theory, but i feel that it would be very messy. And it is complicated enough without the ghci integration, especially as somebody new to this project. Somebody has to do it sometime.

[LeanderK]

just to clarify the current scope of the ticket. I want to:

1. introduce the new package-structure as stated above (this is just moving the packages to the right spot)
2. entangle the packages, so that they reflect the structure.

i have finished point 1 and i am currently working on point 2. Point 2 is a bit more work, but i think its needed. For example i want to move hlint, ghc-mod etc from the haskell-package into the tools package and provide some simple abstractions they can hook into. I also want to remove the dependencies of the cabal-package to the other parts of the project, currently it is referenced all over the place. An example is BuildInfo wich is currently located in Cabal and used even if stack is present. This results in a very bloated and complicated cabal package, because it is hard to reason about whether the code actually deals with cabal or whether it performs some generic build-tool function that is also used by stack. I think especially the cabal refactoring is important, because right now as a programmer it is very difficult to reason about which ghc is called and why, where the BuildInfo comes from etc. I want to get this right before i move on to work on GHCi. My plan is to create 2 pull request, because the changes needed for the 1. point are not really reviewable (a lot of package/import changes), but should not alter behaviour in any way. For the 2. point i have to actually alter the code, maybe introduce some unit tests etc, so these changes can and should be reviewed.