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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
