On Fri, Jun 27, 2003 at 07:27:36PM +0200, Wolfgang Jeltsch wrote:
This brings me to another point. One year ago we had a discussion on The Haskell Mailing List concerning arrows. (The subject of the mails was just "arrows".) The point was that it seemed strange to me that first and second are included in the basic arrow class Arrow while left and right have their extra class ArrowChoice. Not only that it seemed strange to me but it made it impossible to make Parser baseMonad an instance of Arrow. Parser baseMonad has nice implementations of pure and (>>>) but none of first or second.
Your parser type is strange candidate for an arrow: the input (token) type occurs in both positive and negative positions in the type. And does it satisfy identity >>> f = f?
Currently, I use my own Arrow module which provides an arrow class, that doesn't include first and second. I'm really not happy with using a replacement for a module from the hierarchical libraries. Is there any chance of changing the class structure of Control.Arrow?
The point about symmetry is a fair one, but unfortunately the Haskell class system imposes a cost on fine-grained class hierarchies, so we must ask what would be gained. You may have extra instances, but are there extra client programs written to the new interfaces? John Hughes asked this last time, and you pointed out instance PreArrow a => Functor (a b) where fmap f a = a >>> arr f but is that it?