That also makes it possible to cut about 100 lines from Hugs.Base, and remove some #ifndef __HUGS__ stuff from fptools/libraries.
..forcing all users to pay for this very slight internal improvement by way of increased startup times each time Hugs is loaded. Didn't/doesn't look like a Win to me.
I think bringing the structure closer to the Haskell Prelude and the Hierarchial libraries and having things more modular is probably the Right Thing in the long term (for all the usual software engineering reasons) but we're probably shaking things up enough that we should go with a relatively monolithic Prelude at first. (I'm particularily worried that those bits you were loading are from the hierarchial module world - what's the story in the old hierarchial world?) So how about we stay fairly monolithic in this release and look at where it's useful and possible to be more structured for future releases. -- Alastair ps It's probably safe to assume that Hugs isn't going to learn to cope with mutually recursive modules anytime soon. (I came really, really close to making them work about 5 years ago (diffs could probably be tracked down if interested) but came unstuck due to complex interactions with the typechecker.) That being so, we might sometime want to resurrect the trick I used to get round this when building STG-Hugs (first version of which used code taken direct from the Haskell report). What I did was run the dozen or so modules through a preprocessor (nothing fancy, just cpp) which split each module into two parts: 1) A big blob of code with no module header - these were all concatenated to produce Prelude_Core (or whatever I called the module); and 2) A module consisting of the old module header and a body which just imported Prelude_Core so that it could be re-exported. Whether we do this or not depends a bit on how much recursion the libs we use contain - probably not much seeing as how the GHC folk tend to avoid recursion too.