RE: HaXml and HXml toolbox; namespace support
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? Cheers, Simon
On Fri, Mar 19, 2004 at 12:23:22PM -0000, Simon Marlow wrote:
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?
The intention is to make the Hugs distribution a one-stop shop, but allow users to upgrade loosely coupled packages if they wish to. So future releases of Hugs will distinguish two kinds of packages: core ones that are all bundled together, and others (like HaXml, X11, HGL, HOpenGL) that come in their own directories for easy deletion or replacement. (Just delete the directory and slot in a new version.) Some users might appreciate Win32 too, if anyone were interested in testing/fixing it (ditto for GHC, of course).
"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
participants (3)
-
Malcolm Wallace -
Ross Paterson -
Simon Marlow