RE: [Haskell] Weaving the Web with Haskell
At 16:23 03/02/04 +0000, Simon Peyton-Jones wrote:
Having solid libraries for XML and HTTP would be a jolly good thing. As you know, there is plenty of raw material around, but it obviously doesn't do what you want, yet.
I think I'm very close, based on the HXml Toolkit software and a few bits. I was parsing XML directly from the web earlier today, using Hugs on Win32.
If you, together with other interested parties, were to get together to do this, the rest of us would be very grateful. You could do that by directly working on the libraries distributed with GHC and Hugs (we could give you CVS access).
I'd like to see this become part of the standard libraries, when it becomes sufficiently stable and portable. I can't say how Uwe Schmidt feels about this.
Or you could make a separate project of it, and distribute the stuff separately, which would free you from the GHC and Hugs's release cycles.
If the new library infrastructure project takes off, that could be an attractive option. I assume that in due course, the hierarchical libraries would move into such a framework. My goal is to be able to write software that uses an XML library that is easy for people not experienced with Haskell to obtain and load into their running environment. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Graham Klyne
I'd like to see this become part of the standard libraries, when it becomes sufficiently stable and portable.
As far as I can see, there are three (relatively minor) problems with the HXmlToolkit that would currently prevent it becoming part of the standard libraries. (1) It does not use the hierarchical namespace. (2) It relies on obsolete hslibs packages. (2) It is not portable across compilers. On a tangentially related point, portability of several of the existing standard hierarchical libraries is rather patchy too. For instance, the main reason that nhc98 does not currently ship with System.Time from the base package, or any of the network or unix packages, is that the checked-in implementations have a tool-dependency on hsc2hs. (The latter does not appear to have a stand-alone distribution independent of ghc, so it would be necessary to incorporate it into the nhc98 tree, and I don't currently have the time available to untangle hsc2hs's configuration and build system and re-tangle it for nhc98.) I guess I'm with Sigbjorn on wanting to reduce the number of tool dependencies, even though I happen to like GreenCard and hsc2hs for what they can automate. Or perhaps, rather than reducing the dependencies, I want to reduce their impact, by making the tools much easier to get hold of, configure, and install. Regards, Malcolm
participants (2)
-
Graham Klyne -
Malcolm Wallace