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