xml in fptools?

[Malcolm Wallace]

> 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