On Fri, Feb 24, 2006 at 12:13:14PM -0000, Simon Peyton-Jones wrote:
You could imagine a) compiling recursive groups "all at once" b) somehow magically filtering the source file to omit anything undefined, leaving only defined stuff..... which ought to be enough to tie the knot.
jhc does a, then spits out a single .ho for all files in each recursive group. it then links the .ho file to each of the locations it might be searched for. (but it only needs to be found once) there is a method somewhere in between. Though, it will redo a bit of work but should be easier to implement for ghc. Imagine A and B depend on each other. When ghc comes across module A, it sees it depends on B which depends on A. It then renames and typechecks them together as a group but then discards everything but what is defined in A upon conversion to core. so the .o file ends up containing just what is defined in A as is expected. When the compiler gets around to compiling B, the .hi file for A will already be written and up to date, the cycle is broken and B compiles like normal. the main caveat is that one module in each cycle will get typechecked twice, but compared to the total compile time, that is not much overhead at all. I have been meaning to add transparent native recursive module support to haddock, it is only a hundred lines or so I can port from jhc and it would let me provide haddock docs for the jhc standard library. I assume the version in the fptools darcs repo is the one I should be developing against? John -- John Meacham - ⑆repetae.net⑆john⑈