"Simon Marlow"
HaXml ----- + Already part of the common hierarchical library ... and will be distributed as part of the next release of Hugs.
GHC used to ship with HaXml, but we stopped doing this, I believe after discussing it with you. I think the reasoning was that you wanted to be able to distribute new versions of HaXml independently. Is it really a good idea to bundle HaXml with Hugs?
Well, IIRC the reason for wanting independent releases was about keeping up-to-date in a more specific sense: when GHC shipped with HaXml, the code was always woefully out-of-date because there were two separate CVS repositories, my own and the GHC one, and they were structured differently. It was far too much of a pain to maintain and synchronise the two repositories, so the GHC one languished. Now however, the repositories (including ghc/nhc98/Hugs as well as the libraries) are unified, so synchronisation is not a problem. Each compiler should always have the latest version of the library available when a release is forged. Additionally, if you recall, HaXml used to be just one part of the 'text' package, alongside Parsec and various other things, which militated strongly against updating it independently. We now have a more fine-grained package mechanism, which permits the user of a compiler to update an individual package like HaXml in between compiler releases. Hugs handles this by separating the 'contributed' packages into separate directories, distinct from the 'core' packages which install into a single directory hierarchy. (Ghc and nhc98 both use separate directories for all packages.) So basically, we can have the best of both worlds - the ease-of-use and wide availability that comes from bundling libraries with the compiler; the separation of responsibility for library maintenance from the compiler writers onto the library writers; and the possibility of easy interim updates to a library, should the user require it. Regards, Malcolm