You guys should really document that nhc98 support mut. rec. modules too.

Agreed. I believe the Haskell'98 libraries are mutually recursive by definition (Prelude imports Ratio, and Ratio imports the Prelude), so probably all compilers have had to deal with this from the start. nhc98's library implementation is absolutely full of mutually-recursive modules!

Hand-writing .hi files is how GHC used to work (up to version 0.29, IIRC). It's not entirely satisfactory because you can get into situations where you have to 'make' several times to get to a fixed point, and you can construct examples that never reach a fixed point.

I believe, provided the hand-written boot file gives accurate type signatures in the first place, there is no (correctness) need to compile any file a second time. At least, this is the case in nhc98 where the interface file records only type signatures. However, certainly if you /do/ re-compile, often the /sequence/ of signatures in the .hi file never reaches a fixpoint. Although I can see that, because GHC stores optimisation information in the .hi file, you might need to recompile several times to reach a /performance/ fixpoint.

And 'make' complains about recursive dependencies a lot. What does hmake do?

hmake warns the user about the mutually recursive cycle of modules, then goes ahead to compile them (once) in an arbitrary order. Regards, Malcolm

Hello Simon, Friday, July 15, 2005, 6:23:18 PM, you wrote:

...

If you count writing a separate .hs-boot file as being the additional

SM> It used to be Really Fun(TM) when GHC was built like this... you could SM> improve GHC's performance by simply typing 'make' a couple more times to SM> let the inter-module optimisations propagate a bit further :) you can advertise it as "multi-pass optimizing compiler" :) -- Best regards, Bulat mailto:bulatz@HotPOP.com