These are all very good questions! Here&#39;s my stab at it:<br><br><div class="gmail_quote">On Wed, Nov 2, 2011 at 11:28 AM, Ryan Newton <span dir="ltr">&lt;<a href="mailto:rrnewton@gmail.com">rrnewton@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>What is the right interface for a queue?  What is the right interface for a random number generator?</div></blockquote>

<div><br></div><div>For any given class I&#39;d try to get a few experts/interested parties together and discuss.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div>I don&#39;t know, but in both cases you will find many packages on hackage offering different takes on the matter.  In fact, there is a wilderness of alternative interfaces.  We&#39;ve had various discussions on this list about the number of alternative packages.</div>

</blockquote><div><br></div><div>The lack of cohesion in our library offerings is a problem and so is the lack of interfaces. We end up programming against concrete types way too often.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div>I&#39;m fine with lots of packages, but I think it would be great if not every package introduced a new interface as well as a new implementation.  If we could agree as a community on common interfaces to use for some basics, that would probably go a long way towards taming the type class wilderness.  People have mentioned this problem before with respect to &quot;Collections&quot; generally.</div>

</blockquote><div><br></div><div>Aside: The problem with collections is that we don&#39;t have the programming language means to do this well yet (although soon!). The issue is that we want to declare a type class where the context of the methods depends on the instance e.g.</div>

<div><br></div><div>class MapLike m where</div><div>    type Ctx :: Context  -- Can&#39;t do this today!</div><div>    insert Ctx =&gt; k -&gt; v -&gt; m -&gt; m</div><div><br></div><div>Java et all cheats in their container hierarchy by doing unsafe casts (i.e. they never solved this problem)!</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><div><div><div>One basic part of reaching such a goal is separating interface from implementation.  I ran into the following problems just  in the last 24 hours.  In both cases I wanted to use a type class, but didn&#39;t want to depend on the whole package it lived in:</div>



</div></div><div><ul><li>I wanted to use the Benchmarkable class in Criterion in my package.  (Criterion deserving to be a &quot;standard&quot; package.)  But I can&#39;t get that typeclass without depending on the whole Criterion package, which has several dependencies.  And in fact on the machine I was on at the time some of those dependencies were broken, so I decided not to use Benchmarkable.</li>




<li>I wanted to use, or at least support, an existing class for Queues.  I found the following:</li></ul><div><a href="http://hackage.haskell.org/packages/archive/queuelike/1.0.9/doc/html/Data-MQueue-Class.html" target="_blank">http://hackage.haskell.org/packages/archive/queuelike/1.0.9/doc/html/Data-MQueue-Class.html</a></div>

</div></blockquote><div><br></div><div>I think the best option at the moment is to break out type classes in their own packages. That&#39;s what I did with hashable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div>How can we enumerate packages that at least purport to provide standard interfaces that you should both use and pick up to implement?  On a Wiki page?</div></blockquote><div><br></div><div>I would hope that we could get all the important interfaces into the Haskell Platform eventually (and have all packages there use them).</div>

<div><br></div><div>-- Johan</div><div><br></div></div>