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.

Cheers,
Ning
 

From: Ben Gamari <ben@smart-cactus.org>
Date: June 12, 2017 at 11:05:51 AM PDT
To: Simon Peyton Jones <simonpj@microsoft.com>, Sophie Taylor <sophie@traumapony.org>, Michal Terepeta <michal.terepeta@gmail.com>, ghc-devs <ghc-devs@haskell.org>, Ning Wang <email@ningwang.org>
Cc: Kavon Farvardin <kavon@cs.uchicago.edu>
Subject: RE: Removing Hoopl dependency?

Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:

Snip

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].

Cheers,

- Ben


[1] May messages: https://mail.haskell.org/pipermail/ghc-devs/2017-May/014255.html
   June messages: https://mail.haskell.org/pipermail/ghc-devs/2017-June/014293.html