Why does HXT use Arrows?
Something I have been wondering for a while is: Why is HXT built on arrows, rather than monads? I understand that arrows are a generalization of monads, but they also add extra complexity that is often unnecessary. Furthermore, as I understand it they only give you additional power when your arrow cannot implement ArrowApply, since otherwise your arrow is equivalent to a monad anyway, and it looks like the result of parsing an XML document gets you an arrow which implements ArrowApply. Is there some circumstance I am missing where the fact that HXT uses arrows rather than monads lets one do something that one couldn't have done with monads? Cheers, Greg
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...
From John Hughes's AFP lecture notes:
"But whereas monadic computations are parameterised over the type of
their output, but not their input, arrow computations are
parameterised over both. The way monadic programs take input cannot be
varied by varying the monad, but arrow programs, in contrast, can take
their input in many different ways depending on the particular arrow
used."
http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf
Best wishes
Stephen
2009/12/24 Gregory Crosswhite
Something I have been wondering for a while is: Why is HXT built on arrows, rather than monads? I understand that arrows are a generalization of monads, but they also add extra complexity that is often unnecessary. Furthermore, as I understand it they only give you additional power when your arrow cannot implement ArrowApply, since otherwise your arrow is equivalent to a monad anyway, and it looks like the result of parsing an XML document gets you an arrow which implements ArrowApply.
Is there some circumstance I am missing where the fact that HXT uses arrows rather than monads lets one do something that one couldn't have done with monads?
Cheers, Greg
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
On Fri, 25 Dec 2009, Heinrich Apfelmus wrote:
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.
I think this is the way, HXT was designed first. The functions are still available in hxt-filter.
participants (4)
-
Gregory Crosswhite -
Heinrich Apfelmus -
Henning Thielemann -
Stephen Tetley