[Haskell-cafe] Type-class conditional behavior

[Nicholas Tung]

Hi Ryan,

On Sun, May 8, 2011 at 12:06 AM, Ryan Ingram <ryani.spam at 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.

http://www.cs.berkeley.edu/~megacz/garrows/

cheers,
Nicholas — https://ntung.com — CS and Mathematics major @ UC Berkeley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110509/05b58be8/attachment.htm>