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