Removing Hoopl dependency?

[ning w]

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

Simon Peyton Jones via ghc-devs <ghc-devs at 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/piper
mail/ghc-devs/2017-May/014255.html
   June messages: https://mail.haskell.org/piper
mail/ghc-devs/2017-June/014293.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170613/9cb9bc0d/attachment-0001.html>