Michal Terepeta
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