[Haskell-cafe] Why does HXT use Arrows?

[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
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Stephen Tetley]

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 <gcr...@phys.washington.edu>:

[Heinrich Apfelmus]

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

[Henning Thielemann]

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.