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 <b...@smart-cactus.org> *Date:* June 12, 2017 at 11:05:51 AM PDT *To:* Simon Peyton Jones <simo...@microsoft.com>, Sophie Taylor < sop...@traumapony.org>, Michal Terepeta <michal.terep...@gmail.com>, ghc-devs <ghc-devs@haskell.org>, Ning Wang <em...@ningwang.org> *Cc:* Kavon Farvardin <ka...@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/piper mail/ghc-devs/2017-May/014255.html June messages: https://mail.haskell.org/piper mail/ghc-devs/2017-June/014293.html
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
