Is there really a compelling case for forking Hoopl? I was talking to Kavon last week about doing exactly the opposite: using Hoopl more wholeheartedly!
Before going ahead with this, let’s remember the downsides
· If we fork Hoopl, improvements in one place will not be seen in the other. GHC originally used its own containers library but now uses ‘containers’, most of which is irrelevant to GHC, just to pick up the work that has been done to make ‘containers’ fast. Similarly, GHC has a clone of ‘pretty’, but someone is working (I think) to make GHC use ‘pretty’.
· It’s not clear to me why GHC has a clone of parts of Hoopl. Would it not be better just to make Hoopl faster?
If anything I ‘d like to use Hoopl more in Cmm optimisation passes in GHC, so we may want to use more of Hoopl’s facilities.
The main reason you suggest for forking is that there are some awkward name clashes. Surely we could resolve these? e.g we could change CLabel in GHC; or agree with Hoopl maintainers that BlockId would be more helpful than Label.
You mention that Hoopl uses Unique set/map. Why not use ‘containers’ for that? (Like GHC!)
Let’s discuss this a bit more before executing
I’m also interested to know:
· who is actively working on Hoopl (Michael, Sophie, …)?
· how are you using it (within GHC, or somewhere else)?
It’d be good to review and update https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup. Are there any other improvements planned?
Simon
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Michal Terepeta
Sent: 27 May 2017 18:58
To: ghc-devs
Subject: Removing Hoopl dependency?
Hi all,
I was looking at removing the `BlockId` type synonym in favor of
Hoopl's `Label` (there was already a TODO and it is a bit confusing).
But once I've started making the changes, I've realized that in a
bunch of places this makes the code *less* readable. Mostly because of
`CLabel` (sounds similar but is something quite different and having
to rename local variables from `label` to `clabel` is not great).
I started to look at alternatives and noticed that in general the
interface between GHC and Hoopl is quite noisy and confusing:
- Hoopl has `Label` which is GHC's `BlockId` but different than
GHC's `CLabel`
- Hoopl has `Unique` which is different than GHC's `Unique`
- Hoopl has `Unique{Map,Set}` which are different than GHC's
`Uniq{FM,Set}`
- GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is
needed just to filter the exposed functions (filter out some of the
Hoopl's and add the GHC ones).
- Working in `cmm/` requires constant switching between GHC code and
Hoopl (`CmmNode`/`CmmGraph`/`CmmBlock` and dataflow stuff is in GHC,
the actual implementation of `Block`/`Graph` are defined in Hoopl,
etc.)
GHC is actually using only a small subset of Hoopl (e.g., the fixpoint
computation is copied/specialized: `cmm/Hoopl/Dataflow`). So I was
wondering - maybe it's worth to simply drop the dependency on Hoopl?
(and copy the code that is actually necessary in GHC)
I've done an experiment in [1] (to see how much we'd need to actually
copy) and I really like the result:
- We can remove one external dependency and git submodule at the
cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4
modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer
needed)
- We should be able to fix all of the above issues and make the code
easier to understand (less code, everything in one repo, fewer
concepts).
- It's going to be easier to change things since we don't need to
worry about changing the public interface of Hoopl (it's a
standalone package on Hackage and other people already depend on the
current behavior).
What do you think? Does anyone think we shouldn't do this?
Thanks,
Michal
[1] Branch: https://github.com/michalt/ghc/tree/hoopl/no-hooplhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichalt%2Fghc%2Ftree%2Fhoopl%2Fno-hoopl&data=02%7C01%7Csimonpj%40microsoft.com%7Cd1aa41921c50475c170c08d4a52a0f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636315047453651609&sdata=%2F4kb1lqiCv2qTaQyQcuCTxBYTJ0jXmFikSLr%2Bpl8S14%3D&reserved=0
Diff: https://github.com/ghc/ghc/compare/master...michalt:hoopl/no-hooplhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fcompare%2Fmaster...michalt%3Ahoopl%2Fno-hoopl&data=02%7C01%7Csimonpj%40microsoft.com%7Cd1aa41921c50475c170c08d4a52a0f41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636315047453651609&sdata=qLLAD20b4bewj9ItuwkOAPxMMJsXWSQO%2BadMPbSvsHM%3D&reserved=0
For now I just copied the code/updated imports and didn't do any
cleanups, but I'd be happy to do them in subsequent PRs
