Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0

[Uwe Schmidt]

Hi Gregory,

> > As I understood, John Hughes invented the arrows as a generalisation
> > of monads, you say it's a less powerful concept. I'm a bit puzzled with
> > that. Could you explain these different views.
> >
> 
> Consider the following example:
> 
>      f :: Int -> m a
>      f i = monads !! (i *5 `mod` length monads)
>          where
>              monads = [...] :: [m a]
> 
> In this case, we see that the action chosen by f is a non-trivial 
> function of the input argument.  In general, there is no way that we can 
> represent this equivalently as an arrow.  The reason why is because, 

thanks for the explanation, I thik I got that.

> > So, your advice is to throw away the whole arrow stuff in hxt-10 and
> > redefined (or rename) the combinators on the basis of monads?
> > ...
> Yes, of course it is!!!  Of course, given how much work you put into 
> hxt, you would most likely be a fool if you actually took my advice...  ;-)

Of course the remark about hxt-10 wasn't meant to be totally serious.

> So, no, despite the way I am probably coming across I am not actually 
> trying to convince you to rewrite your library from scratch to use 
> monads.  My actual goals are twofold:  First (driven by genuine 
> curiosity) to see if there is something that I missed that made arrows 
> be the natural choice for you to use in your library.  Second, to try 
> and convince people in the future who are considering basing their 
> libraries on arrows that they should only do this if monads do not give 
> them enough power as library authors.

I'm not really convinced of your point of view.  I agree much more with the
point of view that Sebastiaan Visser described in his post. Let me explain this.

HXT as other libraries (HXML, HaXml) defines an embedded DSL for processing XML.
When starting to work with this DSL, the main task for a user is to understand the
semantics of this DSL, the underlying data types, the primitive operations, the
combinators, how to execute a DSL program, and how to plug in own primitive
operations.

In HXT, the concept of a filter is the most important one. This concept
is a natural generalisation of a function (and that's what arrows are).
A user has to grasp this idea of a filter. And he/she can do
this even without knowing anything about arrows or monads.  
People knowing a little bit of Unix pipes and filter will become
easily familiar with the simple parts of this DSL.

As a user of this DSL, I'm not really interested whether it's implemented with arrows,
with monads, or something else, I just want to have the right combinators
to formulate the task to be performed by the program.

From the point of an implementer, we agree, that for HXT
an arrow based implementation
is equivalent to a monad based one. So there's no open point.

The intention with HXT was not to build a general purpose languages, where you can do
any kind of complex things. The intention was to build a (rather) simple and
and powerful language for processing XML, nothing more.
You may of course argue, whether we've found the right set of combinators,
but that's another story.
As Sebasiaan wrote in this reply, when processing XML, the cases
for higher order computations are not very frequent. The few combinators
available for this are, from a "Real World Haskell" point of view, sufficient.

To sum it up, I think, from an implementers point of view for this eDSL, we agree that both
ways arrows/monads are possible and rather similar. From a users point of
view, I prefer a simple and specialised DSL, you would prefer a more general one. 

Cheers,

  Uwe