Hi Isaac,
I've had similar thoughts before. Once GHC can read and write external
Core this should become a half hour hack. I did a similar thing in
Yhc, and it really is trivial
(http://darcs.haskell.org/yhc/src/compiler98/Core/Linker.hs). I'm sure
there would be a few corner cases, but those kind of things can easily
be patched over.
I think there would be speed improvements, but not as dramatic as for
something that was designed to do whole-program from the outset.
Thanks
Neil - who really wants external Core
On 12/23/07, Isaac Dupree
GHC optimizes less effectively when parts of a program are in different modules, or are exported from a module. Therefore, merging all the code into one "module Main (main)" would help. Unfortunately, Haskell source syntax is ill-suited to this; for example:
module-boundary monomorphism restriction different defaults in different modules deriving (Show, Read) --for renaming everything that's -- in different modules, so it doesn't conflict new GHC "{..}" etc. record stuff imports as, unknown import lists....
Also, program correctness can be wrongly increased; for example, using instances that were defined in some module imported by Main, but not by the module that uses the instance. I suppose this might affect overlapping instances somehow?
But it seems plausible to merge modules on the GHC Core level, after desugaring and type-checking. Then the one infelicity would be that orphan RULES could apply in more places (RULES are converted and applied to Core!). Is this a problem? Does it already happen when modules import small inlinings from .hi files of modules that don't have access to the RULES?
It would not actually be quite "whole-program" as long as all the libraries are compiled separately and only available through their .o and incomplete .hi files. Which is okay; but it would be nice if they could all also be compiled to the "complete-.hi" that we thought might serve for External Core -- and then one would just need to tell GHC to take all those complete-.hi's and compile them together into one executable. (except for complications like C _stub files, etc, etc. Also some parts of `base` might be wired-in enough that they need some thought before messing with them.) Then _any_ function that was only used once would be inlined, and GHC would generally be free to make decisions like that (at the GHC-speed price of having to look at all program and library code in detail) (however the GHC interface to this works, Cabal could probably help automate it somehow?)
(Unfortunately, ghc-haskell source syntax doesn't provide an easy way to encode Core, even if we wanted to convert it back into GHC-compilable Haskell, without unsafeCoerce everywhere, I think?)
So it's more complicated than it seems on the surface, but it could be done; I only wonder how effective it would be on various programs. I assume GHC doesn't currently implement any optimizations that can _only_ be whole-program, so it would still not be quite like Jhc, though this basic support might allow some such optimizations to be implemented.
Isaac _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users