*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
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
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/