On Sun, May 8, 2011 at 12:06 AM, Ryan Ingram
<ryani.spam@gmail.com> wrote:
However we know the behavior of these functions, and you can hack around it with a manual show instance that takes advantage of that knowledge:
instance Show t => Show (AV t) where
show (AVLeft a) = drop 5 $ show (Left a)
That's a creative way to think about it, but unfortunately, the types don't quite work out:
(AVLeft a) :: AV (Either ta tb)
a :: AV ta
Left a :: Either (AV ta) tc
Since the argument of AVLeft is another AV.
All this said, I agree that the presence of 'arr' in Arrow is a problem for many types of generalized computing. It overly constrains what can be an arrow, in my opinion. I think a better analysis of the primitives required for arrow notation to work would solve a lot of problems of this type.
Yes, a graduate student here at UC Berkeley (Adam Megacz) is working on a project (Generalized Arrows) to alleviate this difficulty. I think the arrow notation not only unnecessarily prevents adding things like Show as typeclass constraints, but also makes it difficult to use an alternate Either / tuple type, like the AVLeft above, since you can't look inside the little functions it creates, like "\x -> (x, x)", which is ga_copy in Adam's work.
cheers,