Hi Ryan, On Sun, May 8, 2011 at 12:06 AM, Ryan Ingram <[email protected]> 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. http://www.cs.berkeley.edu/~megacz/garrows/ cheers, Nicholas — https://ntung.com — CS and Mathematics major @ UC Berkeley
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
