[Haskell-cafe] Re: Why does HXT use Arrows?

[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