Stephen Tetley wrote:
Hello Gregory
I've never used HXT, but looking at the source there are many functions with types like this one:
getElemNodeSet :: ArrowXml a => a XmlTree XmlTree -> a XmlTree XmlNodeSet
They are functions where the arrow is 'a XmlTree _something_. The input to the arrow is an XmlTree and the ouput is variable. If all the functions were like this they could be replaced by a monad. However there are quite a few like this:
mkCmt :: a String XmlTree mkElement :: QName -> a n XmlTree -> a n XmlTree -> a n XmlTree
Here the input type to the arrow computation varies - this is the key - monads can produce output in many ways (wrapping it in a Maybe, tupling it with state, many results - list monad) but they can only take input as function parameters. Arrows can consume input in different ways...
Which begets the question of whether HXT actually uses a way of taking input other than as function parameter. It appears to me that it doesn't. Put differently, I suspect that all of HXT can be rewritten to mkCmt :: String -> M XmlTree mkElement :: QName -> (n -> M XmlTree) -> (n -> M XmlTree) -> (n -> M XmlTree) ArrowXML a => a b c ~=~ b -> M c with M a = [a] being the list monad or some list augmented with IO. At least, that's what I gather from the presentation in the original paper Wallace und Runciman. Haskell and XML: Generic Combinators or Type-Based Translation? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.4029 I am not convinced that the abstract arrow interface is more convenient than an explicit b -> M c version. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com