Re: Removing Hoopl dependency?

[Ben Gamari]

Michal Terepeta  writes:

> 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



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing Hoopl dependency?

[Michal Terepeta]

> 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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs