Removing Hoopl dependency?

[Ben Gamari]

Michal Terepeta <michal.terepeta at gmail.com> writes:

> Maybe this is the core of our disagreement - why is it a good idea to
> have Hoopl as a separate package in the first place?
>
> I've pointed multiple reasons why I think it has a significant cost.
> But I don't really see any major benefits. Looking at the commit
> history of Hoopl there hasn't been much development on it since 2012
> when Simon M was trying to get the new GHC backend working (since
> then, it's mostly maintenance patches to keep up with changes in
> `base`, etc).
> Extracting a core part of any project to a shared library has some
> real costs, so there should be equally real benefits that outweigh
> that cost. (If I proposed extracting parts of Core optimizer to a
> separate package, wouldn't you expect some really good reasons for
> doing this?)

One way forward here would be to ask those who would be affected by a
API rework whether they would be open to change. I don't believe there
are too many hoopl users at the moment but I recall that previous
efforts to change the library's interface were met with some resistance.

However, even if we found that hoopl's current user-base is agreeable to
change we would still need to account for the fact that advancing GHC
in lockstep with an out-of-tree hoopl will take more effort than
advancing it under Michal's merge proposal. Admittedly, with submodules
this additional effort isn't too large, but it's still more than having
hoopl and GHC under one tree.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170608/cedd6734/attachment.sig>