C.M.Brown wrote:
I don't really see this as being any kind of real issue at all. Surely all GHC needs to do is to concatenate all the modules together, alpha-reduce the import/export relations and do a compile/type check over the concatenated module.
FWIW, I agree (in principle -- I haven't looked at the GHC implementation enough to see whether its internal representations could easily do type inference involving symbols in multiple modules, and GHC HQ understandably isn't interested in implementing it themselves http://hackage.haskell.org/trac/ghc/ticket/1409 ).
There is a bit of a question in my mind about what to do with .hi/.o files for the combined blob.
There's also a scalability / memory use issue, that is also the plug for separate compilation: if you make really big modules (whether manually or programmatically), compiling them takes lots of memory and time, significantly more total time and maximum memory than you need for via separate compilation. I consider this a bug. (Well, I don't know if what I said is true -- it's just an excuse that's often given for why GHC compiling things together is a bad idea. And there are several compile-time performance bugs in Trac.) Admittedly, it's a challenging problem to automatically segment a large module so you only need to do a little work at once. Essentially, the module system partly has the purpose of telling the compiler how not to try to optimize, even if it would be beneficial; and thereby you get reasonable compilation times. This would be inexcusable in my mind if the same sort of module segmentation didn't also help *humans* understand the contents of the modules :-). I wonder if there can be some sort of system with pragmas that accomplishes the same purpose of guiding the compiler... probably not for Haskell so much as in general
-Isaac _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
