Simon Marlow wrote:
I'd like to see the community settle on a single XML API if possible, but I imagine that will probably happen over time in any case. Perhaps someone could offer to lead a group to work on standardising an API?
The motivation here is to have a standard API for e.g. parsing an XML file. I'm sure it would be easy to agree on some signatures like readXml :: String -> Maybe XML showXml :: XML -> String fReadXml :: FilePath -> IO XML fWriteXml :: FilePath -> XML -> IO () hGetXml :: Handle -> IO XML hPutXml :: Handle -> XML -> IO () but the real question, or difference between implementations, is the representation of the datatype called XML above. HaXml already has a version of these functions using a class instead of a type, i.e. replace all instances of XML with (XmlContent a => a). But once the XML file has been parsed, the rest of the program is going to want to do some processing on the tree. So ultimately, any one program is going to fix the instantiated type of the class to something in particular, whether that be HaXml's generic Document, or HXT's equivalent, or hxml's event stream, or some DtdToHaskell-generated types. As such, I don't see how the common API helps much. The basic parsing job might share the same name across libraries, but the much more important processing steps will not (and perhaps cannot?). In the OO world, they came up with a common generic API (the DOM) because the physical representation of the tree is hidden - you can only access it by function calls, not pattern-matching. Good FP style tends to do the opposite, revealing the representation. Regards, Malcolm