Re: Removing Hoopl dependency?

Ben, Simon, Thanks, that's good to know! On Tue, 13 Jun 2017 at 07:48 Simon Peyton Jones wrote: > Speaking of which, what policies are there on bringing in new dependencies > to GHC, both compile-time and run-time (e.g. possible SMT solver support)? > > > > We don’t have

RE: Removing Hoopl dependency?

Speaking of which, what policies are there on bringing in new dependencies to GHC, both compile-time and run-time (e.g. possible SMT solver support)? We don’t have a formal policy, but we are generally reluctant to take on new dependencies. For SMT solvers, Iavor is using one via a

8.2.1 Status

Hello everyone, GHC 8.2.1 release candidate 2 has been out for a few weeks now and, while it turned up a number of issues, it seems that the release is (slowly) solidifying. Currently the ghc-8.2 branch has nearly 50 commits since the -rc2 tag, fixing many of the issues that have been reported.

Re: WordX/IntX wrap Word#/Int#?

Thanks a lot for the replies & links! I'll try to finish Simon's diff (and probably ask silly questions if I get stuck ;) Cheers, Michal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing Hoopl dependency?

Sophie Taylor writes: > I don't see why not, other than possible duplication of effort when it > comes to some of the basic algorithms. > > Speaking of which, what policies are there on bringing in new dependencies > to GHC, both compile-time and run-time (e.g. possible

Re: Removing Hoopl dependency?

> On Mon, Jun 12, 2017 at 8:05 PM Ben Gamari wrote: > Simon Peyton Jones via ghc-devs 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

RE: Removing Hoopl dependency?

Simon Peyton Jones via ghc-devs 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

Re: Removing Hoopl dependency?

I don't see why not, other than possible duplication of effort when it comes to some of the basic algorithms. Speaking of which, what policies are there on bringing in new dependencies to GHC, both compile-time and run-time (e.g. possible SMT solver support)? On Mon, 12 Jun 2017 at 17:07 Simon

RE: Removing Hoopl dependency?

Interesting! Maybe there are a couple of different alternatives: A. A rewrite of Hoopl, with all the same basic ideas and data structures, but with a better API (I’m not sure exactly in what way, but Michael has some idea, as does Sophie), and a more efficient implementation. B. A