Removing Hoopl dependency?

Fri Jun 9 08:31:44 UTC 2017

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 <ghc-devs at haskell.org> 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:michal.terepeta at gmail.com] 
> Sent: 08 June 2017 19:59
> To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-devs at haskell.org>
> Cc: Kavon Farvardin <kavon at cs.uchicago.edu>
> Subject: Re: Removing Hoopl dependency?
>  
> > On Wed, Jun 7, 2017 at 7:05 PM Simon Peyton Jones <simonpj at microsoft.com> 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
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs