Removing Hoopl dependency?

ning w email at
Wed Jun 14 01:24:36 UTC 2017

Thanks Ben.

Both A and B (mentioned in Simon's reply) are good alternatives as long as
existing Hoopl users are NOT forced to upgrade when they upgrade Cable or
Stackage.  Otherwise, we will see more forks of Hoopl.   Once Cable and
Stackage gain the multi-version capability, A and B can be merged back to
Hoopl as a major release.

In my experience, Hoopl based optimizations/program analyses tend to use a
lot of memory, but they are also easy to verify. So it's still a useful
tool in some special use cases.  If the performance of Hoopl can be
improved, it will certainly be more useful.


*From:* Ben Gamari <ben at>
*Date:* June 12, 2017 at 11:05:51 AM PDT
*To:* Simon Peyton Jones <simonpj at>, Sophie Taylor <
sophie at>, Michal Terepeta <michal.terepeta at>,
ghc-devs <ghc-devs at>, Ning Wang <email at>
*Cc:* Kavon Farvardin <kavon at>
*Subject:* *RE: Removing Hoopl dependency?*

Simon Peyton Jones via ghc-devs <ghc-devs at> writes:


That would leave Sophie free to do (B) free of the constraints of GHC

depending on it; but we could always use it later.

Does that sound plausible?  Do we know of any other Hoopl users?

CCing Ning, who is currently maintaining hoopl and I believe has some
projects using it.

Ning, you may want to have a look through this thread if you haven't
already seen it. You can find the previous messages in the list archive [1].


- Ben

[1] May messages:
   June messages:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list