Re: hoopl questions

Brett, if you'd like to do some work on Hoopl and contribute to GHC at the same time please take a look here: http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup This page sumarizes some conclusions Simon and I reached during my summer internship. In the end I didn't have enough time to implement them and most likely I won't. Maybe you'd be interested in picking up that project? Janek Dnia środa, 23 października 2013, Austin Seipp napisał:

*Sigh*. Resending to list from the correct email...

-------------------

Part of it, probably, is that Hoopl actually costs quite a bit in terms of efficiency, both in use (e.g. compiler paasses) and integration (i.e. using the library at all.) Simon Marlow spent quite a lot of time bringing the new code generator up-to-par with the old one in terms of compilation time, but it was a tough battle. In particular, you'll notice all the Monad types from Hoopl are actually specialized to hell in the compiler, and this is precisely the reasons for doing so.

On the whole, Hoopl will probably always cost a little more - the new backend requires more passes due to its design, so there will always be some cost associated with that. But we only want that cost, and not the Hoopl overhead itself. :) If you can find a way to introduce new passes or more flexible optimizations, I'm sure we'd still like to look at them, though.

On Wed, Oct 23, 2013 at 8:53 AM, Brett Letner wrote:

...

...

As for the transformations you're trying to implement. You are aware that they are already implemented in GHC but without Hoopl?

Is that because the ghc code just hasn't been updated yet (no need to if it is already working) or because those sorts of transformations are outside the scope of what hoopl does (or was intended to do)?

Thank you, Brett

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs