Removing Hoopl dependency?

[Simon Peyton Jones]

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 at haskell.org] On Behalf Of Michal Terepeta
Sent: 27 May 2017 18:58
To: ghc-devs <ghc-devs at haskell.org>
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-hoopl<https://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-hoopl<https://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170528/4cd47ba6/attachment-0001.html>