While we're at it, how about one or more classes in between Category/Compositor and Arrow?  One example is DeepArrow (see wiki page [1] and haddock docs [2]).  Sample instances: functions and transformers of typed type representations, UIs, code, and pairs of same.  I've currently structured DeepArrow as a subclass of Arrow, but most of my instances do not have arr.  Any real arrow (including arr) is a DeepArrow (or almost), as the haddock docs mention.
<br><br>DeepArrow could benefit from suggestions (perhaps refactoring), and I would appreciate such input.&nbsp; In any case, I imagine there&#39;s some rich, useful structure between Category &amp; Arrow, and now would be a great time to explore it before settling on a new class hierarchy.
<br><br>Cheers,&nbsp; - Conal<br><br>[1] <a href="http://haskell.org/haskellwiki/DeepArrow">http://haskell.org/haskellwiki/DeepArrow</a><br>[2] <a href="http://darcs.haskell.org/packages/DeepArrow/doc/html/Control-Arrow-DeepArrow.html">
http://darcs.haskell.org/packages/DeepArrow/doc/html/Control-Arrow-DeepArrow.html</a><br><br><br><div><span class="gmail_quote">On 10/13/07, <b class="gmail_sendername">Ashley Yakeley</b> &lt;<a href="mailto:ashley@semantic.org">
ashley@semantic.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="http://hackage.haskell.org/trac/ghc/ticket/1773">
http://hackage.haskell.org/trac/ghc/ticket/1773</a><br>(darcs patch attached to ticket)<br><br>The Compositor class has two members:<br><br>&nbsp;&nbsp;class Compositor comp where<br>&nbsp;&nbsp;&nbsp;&nbsp;identity :: comp a a<br>&nbsp;&nbsp;&nbsp;&nbsp;(&gt;&gt;&gt;) :: comp a b -&gt; comp b c -&gt; comp a c
<br><br>with the obvious monoid. Since all Arrows are Compositors, make<br>Compositor a superclass of Arrow.<br><br>A number of useful types are Compositors but not Arrows:<br><br>1. Bijections<br><br>&nbsp;&nbsp; data Bijection a b = MkBijection (a -&gt; b) (b -&gt; a)
<br><br>2. Codecs, i.e. encoder/decoder pairs such as charset converters<br><br>&nbsp;&nbsp; data Codec base derived = MkCodec<br>&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; encode :: derived -&gt; base,<br>&nbsp;&nbsp;&nbsp;&nbsp; decode :: base -&gt; Maybe derived -- or other Monad
<br>&nbsp;&nbsp; }<br><br>&nbsp;&nbsp; utf8 :: Codec [Word8] String<br>&nbsp;&nbsp; xml :: Codec String XML<br><br>3. Lenses<br>These make updatable sections of data structures.<br><br>&nbsp;&nbsp; data Lens s t = MkLens<br>&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp; lensGet :: s -&gt; t,<br>
&nbsp;&nbsp;&nbsp;&nbsp; lensPutback :: t -&gt; s -&gt; s<br>&nbsp;&nbsp; }<br><br>See <a href="http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf">http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf</a><br><br>4. Reified proofs of type identity
<br>&nbsp;&nbsp; These are useful if you use GADTs and type-witnesses a lot.<br><br>&nbsp;&nbsp; newtype SameType a a&#39; = MkSameType (forall f. f a -&gt; f a&#39;)<br><br>Proposal period: two weeks, until 10-27<br><br>_______________________________________________
<br>Libraries mailing list<br><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/libraries">http://www.haskell.org/mailman/listinfo/libraries</a><br></blockquote>
</div><br>