Lemme toss in my 2 cents as an outsider who likes to dabble in programming language and compilers: I would *love* to be able just drop in (parts) of GHC's optimisation into my toy compilers. Optimisation is complicated, lots of work, and not really the part I care about when toying with languages. I wasn't really aware of Hoopl before this thread, so now that I do I'm kinda sad by the idea of this reusable infrastructure being tossed out. I don't really have any vested interest/opinion on how to deal with the current Hoopl situation, so if it's decided to write a Hoopl2.0 instead, without backwards compatibility, I would still consider that a win.
Cheers, Merijn > On 9 Jun 2017, at 9:50, Simon Peyton Jones via ghc-devs > <[email protected]> wrote: > > 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? > > > One reason only: because it makes Hoopl usable by compilers other than GHC. > And, dually, efforts by others to improve Hoopl will benefit GHC. > > If I proposed extracting parts of Core optimizer to a separate package, > wouldn't you expect some really good reasons for doing this? > > > A re-usable library should be > a) a significant chunk of code, > b) that can plausibly be re-purposed by others > c) and that has an explicable API > > I think the Core optimiser is so big, and so GHC specific, that (b) and (c) > are unlikely to hold. But we carefully designed Hoopl from the ground up so > that it was agnostic about the node types, and so can be re-used for control > flow graphs of many kinds. It’s designed to be re-usable. Whether it is > actually re-used is another matter, of course. But if it’s part of GHC, it > can’t be. > > Stackage only allows one version of each package > > I didn’t know that, but I can see it makes sense. That makes a strong case > for re-doing it as a new package hoopl2, if the API needs to change > substantially (something we have yet to discuss). > > I've pointed multiple reasons why I think it has a significant cost. > > Can you just summarise them again briefly for me? If we are free to choose > nomenclature and API for hoopl2, I’m not yet seeing why making it a separate > package is harder than not doing so. E.g. template-haskell is a separate > package. > > Thanks! > > Simon > > > > From: Michal Terepeta [mailto:[email protected]] > Sent: 08 June 2017 19:59 > To: Simon Peyton Jones <[email protected]>; ghc-devs > <[email protected]> > Cc: Kavon Farvardin <[email protected]> > Subject: Re: Removing Hoopl dependency? > > > On Wed, Jun 7, 2017 at 7:05 PM Simon Peyton Jones <[email protected]> > > 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 > > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
