<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Francesco Mazzoli &lt;<a href="mailto:f@mazzo.li" target="_blank">f@mazzo.li</a>&gt;<br>

<br>
At Sat, 10 Nov 2012 15:16:30 +0100,<br>
Alberto G. Corona  wrote:<br>
&gt; There is a ListLike package, which does this nice abstraction. but I don&#39;t<br>
&gt; know if it is ready for and/or enough complete for serious usage.  I?m<br>
&gt; thinking into using it for the same reasons.<br>
&gt;<br>
&gt; Anyone has some experiences to share about it?<br>
<br>
I&#39;ve used it in the past and it&#39;s solid, it&#39;s been around for a while and the<br>
original author knows his Haskell.<br>
<br>
Things I don&#39;t like:<br>
<br>
* The classes are huge:<br>
  &lt;<a href="http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-ListLike.html#t:ListLike" target="_blank">http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-ListLike.html#t:ListLike</a>&gt;.<br>


  I&#39;d much rater prefer to have all those utilities functions outside the type<br>
  class, for no particular reason other then the ugliness of the type class.<br></blockquote><div><br></div><div>Speaking as the ListLike maintainer, I&#39;d like this too.  But it&#39;s difficult to do so without sacrificing performance.  In some cases, sacrificing *a lot* of performance.  So they have to be class members.</div>
<div><br></div><div>However, there&#39;s no reason ListLike has to remain a single monolithic class.  I&#39;d prefer an API that&#39;s split up into several classes, as was done in Edison.  Then &#39;ListLike&#39; itself would just be a type synonym, or possibly a small type class with the appropriate superclasses.</div>
<div><br></div><div>However this seems like a lot of work for relatively little payoff, which makes it a low priority for me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* It defines its own wrappers for `ByteString&#39;:<br>
  &lt;<a href="http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-ListLike.html#t:CharString" target="_blank">http://hackage.haskell.org/packages/archive/ListLike/3.1.6/doc/html/Data-ListLike.html#t:CharString</a>&gt;.<br>
</blockquote><div><br></div><div>The community&#39;s view on newtypes is funny.  On the one hand, I see all the time the claim &quot;Just use a newtype wrapper to write instances for ...&quot; (e.g. the recent suggestion of &#39;instance Num a =&gt; Num (a,a)&#39;.  On the other, nobody actually seems to want to use these newtype wrappers.  Maybe it clutters the code?  I don&#39;t know.</div>
<div><br></div><div>I couldn&#39;t think of a better way to implement this functionality, patches would be gratefully accepted.  Anyway, you really shouldn&#39;t use these wrappers unless you&#39;re using a ByteString to represent ASCII text.  Which you shouldn&#39;t be doing anyway.  If you&#39;re using a ByteString to represent a sequence of bytes, you needn&#39;t ever encounter CharString.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
* It doesn&#39;t have instances for `Text&#39;, you have to resort to the<br>
  `listlike-instances&#39; package.<br></blockquote><div><br></div><div>Given that text and vector are both in the Haskell Platform, I wouldn&#39;t object to these instances being rolled into the main ListLike package.  Any comments on this?</div>
<div><br></div><div>John L. </div></div></div>