[Haskell-cafe] Cyclic Inclusions

[Isaac Dupree]

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