<div dir="ltr"><div><div><div><div>> On Wed, Jun 7, 2017 at 7:05 PM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:</div><div>> Michael</div><div>>  </div><div>> Sorry to be slow.</div><div>>  </div><div>> > Note that what I’m actually advocating is to *finish* forking Hoopl. The</div><div>> > fork really started in ~2012 when the “new Cmm backend” was being</div><div>> > finished.</div><div>>  </div><div>> 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?</div><div>>  </div><div>> > apart from the performance</div><div>> > (as noted above), there’s the issue of Hoopl’s interface. IMHO the</div><div>> > node-oriented approach taken by Hoopl is both not flexible enough and it</div><div>> > makes it harder to optimize it. That’s why I’ve already changed GHC’s</div><div>> > `Hoopl.Dataflow` module to operate “block-at-a-time”</div><div>>  </div><div>> 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.</div><div><br></div><div>Sure, but re-engineering the API of a publicly use package has significant</div><div>cost for everyone involved:</div><div>- GHC: we might need to wait longer for any improvements and spend</div><div>  more time discussing various options (and compromises - what makes</div><div>  sense for GHC might not make sense for other people)</div><div>- Hoopl users: will need to migrate to the new APIs potentially</div><div>  multiple times</div><div>- Hoopl maintainers: might need to maintain more than one branches of</div><div>  Hoopl for a while</div><div><br></div><div>And note that just bumping a version number might not be enough.  IIRC</div><div>Stackage only allows one version of each package and since Hoopl is a</div><div>boot package for GHC, the new version will move to Stackage along with</div><div>GHC. So any users of Hoopl that want to use the old package, will not</div><div>be able to use that version of Stackage.</div><div><br></div><div>> > When you say</div><div>> > that we should “just fix Hoopl”, it sounds to me that we’d really need</div><div>> > to rewrite it from scratch. And it’s much easier to do that if we can</div><div>> > just experiment within GHC without worrying about breaking other</div><div>> > existing Hoopl users</div><div>>  </div><div>> 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.</div><div><br></div><div>Maybe this is the core of our disagreement - why is it a good idea to</div><div>have Hoopl as a separate package in the first place?</div><div><br></div><div>I've pointed multiple reasons why I think it has a significant cost.</div><div>But I don't really see any major benefits. Looking at the commit</div><div>history of Hoopl there hasn't been much development on it since 2012</div><div>when Simon M was trying to get the new GHC backend working (since</div><div>then, it's mostly maintenance patches to keep up with changes in</div><div>`base`, etc).</div><div>Extracting a core part of any project to a shared library has some</div><div>real costs, so there should be equally real benefits that outweigh</div><div>that cost. (If I proposed extracting parts of Core optimizer to a</div><div>separate package, wouldn't you expect some really good reasons for</div><div>doing this?)</div><div>I also do think this is quite different than a dependency on, say,</div><div>`binary`, `containers` or `pretty`, where the API of the library is</div><div>smaller (at least conceptually), much better understood and</div><div>established.</div><div><br></div><div>Cheers,</div><div>Michal</div></div></div></div><div><br></div></div>