Speaking of Identity, are there compelling reasons for it to be under Control.Monad?  Of course Identity is a Monad, but it's in many other type classes as well.  Similarly, I wonder why Monad is under Control, since monads are not always about control.
<br><br>More deeply, I wonder if type classes and module hierarchy are adversarial notions.&nbsp; Type classes are powerful because they cut across many different kinds of uses.&nbsp; Thus exactly where they&#39;re useful, they&#39;re also hard to classify (assign to a slot in the hierarchy).
<br><br>Just to be clear: I&#39;m raising an issue for discussion.&nbsp; I don&#39;t have a proposal or even a direction.<br><br>- Conal<br><br><div><span class="gmail_quote">On 3/26/07, <b class="gmail_sendername">Neil Mitchell
</b> &lt;<a href="mailto:ndmitchell@gmail.com">ndmitchell@gmail.com</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;">Hi<br>
<br>I&#39;m not a massive Control.Monad user, but:<br><br>&gt; The plan is to split Control.Monad.Identity, Control.Monad.Trans and<br>&gt; Control.Monad.Trans.* off into a separate (portable) package.<br><br>Isn&#39;t Control.Monad.Identity
 very simple, very short and totally<br>Haskell 98? Why can&#39;t it go in the standard MTL? I&#39;ve only used State<br>and Identity out of all the monads in MTL.<br><br>Thanks<br><br>Neil<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>