cvs commit: hugs98/libraries Prelude.hs

[Alastair Reid]

>> 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.