[Haskell-cafe] Re: Why does HXT use Arrows?
apfelmus at quantentunnel.de
Fri Dec 25 05:51:23 EST 2009
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?
I am not convinced that the abstract arrow interface is more convenient
than an explicit b -> M c version.
More information about the Haskell-Cafe