Re: Removing Hoopl dependency?

On Wed, Jun 7, 2017 at 7:05 PM Simon Peyton Jones wrote: Michael

Sorry to be slow.

...

Note that what I’m actually advocating is to *finish* forking Hoopl. The fork really started in ~2012 when the “new Cmm backend” was being finished.

Yes, I know. But what I’m suggesting is to revisit the reasons for that fork, and re-join if possible. Eg if Hoopl is too slow, can’t we make it faster? Why is GHC’s version faster?

...

apart from the performance (as noted above), there’s the issue of Hoopl’s interface. IMHO the node-oriented approach taken by Hoopl is both not flexible enough and it makes it harder to optimize it. That’s why I’ve already changed GHC’s `Hoopl.Dataflow` module to operate “block-at-a-time”

Well that sounds like an argument to re-engineer Hoopl’s API, rather an argument to fork it. If it’s a better API, can’t we make it better for everyone? I don’t yet understand what the “block-oriented” API is, or how it differs, but let’s have the conversation.

Sure, but re-engineering the API of a publicly use package has significant cost for everyone involved: - GHC: we might need to wait longer for any improvements and spend more time discussing various options (and compromises - what makes sense for GHC might not make sense for other people) - Hoopl users: will need to migrate to the new APIs potentially multiple times - Hoopl maintainers: might need to maintain more than one branches of Hoopl for a while And note that just bumping a version number might not be enough. IIRC Stackage only allows one version of each package and since Hoopl is a boot package for GHC, the new version will move to Stackage along with GHC. So any users of Hoopl that want to use the old package, will not be able to use that version of Stackage.

...

When you say that we should “just fix Hoopl”, it sounds to me that we’d really need to rewrite it from scratch. And it’s much easier to do that if we can just experiment within GHC without worrying about breaking other existing Hoopl users

Fine. But then let’s call it hoopl2, make it a separate package (perhaps with GHC as its only client for now), and declare that it’s intended to supersede hoopl.

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?) I also do think this is quite different than a dependency on, say, `binary`, `containers` or `pretty`, where the API of the library is smaller (at least conceptually), much better understood and established. Cheers, Michal