<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I realise my remarks are far too late, but unfortunately I have not been actively following all the places where discussions about Haskell's future take place; I have never used Foldable etc. But nevertheless I want to throw in my few cents.<div class=""><br class=""></div><div class="">The function foldr for lists can be "generalised" in two ways:</div><div class=""><br class=""></div><div class=""> - the way I have always been teaching it is as a first example of a homomorphism. In that sense a better name for it would have been "cata", or even "(|" with "|)", </div><div class=""> i.e. using the banana brackets. Maybe I should rewrite our lecture notes and replace all uses of foldr by uses of cata.</div><div class=""> - since lists are monoids is can also be generalised into a function which has a monoid as its co-domain, and this is what is the idea behind the class Foldable. </div><div class=""> The originally proposed name for this was "crush", as described in <a href="http://www.kestrel.edu/home/people/meertens/publications/papers/Calculate_polytypically.pdf" class="">http://www.kestrel.edu/home/people/meertens/publications/papers/Calculate_polytypically.pdf</a></div><div class=""><br class=""></div><div class="">In my teaching I have always been placing emphasis on the first aspect of foldr, and hence I do not like the (name of the)) class Foldable at all, and hence not the FT proposal. Fold should have been called crush and Foldable should have been named Crushable. Had this been done, none of the current problems would have occurred. Maybe we just should phase out all uses of fold(r) etc. and replace them by calls to crush and cata.</div><div class=""><br class=""></div><div class=""> Doaitse</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 04 Feb 2015, at 18:01 , Edward Kmett <<a href="mailto:ekmett@gmail.com" class="">ekmett@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">The current step was to generalize them so that code that imported Data.List so that they don't conflict with the Prelude versions.<div class=""><br class=""></div><div class="">The intent was that once we gained the ability to deprecate re-exports that we'd remove them entirely. We now have a patch that enables us to do such things.</div><div class=""><br class=""></div><div class="">It turns out that if you look at hackage, for the most part folks are actually importing Data.List unqualified to bring into scope <font face="monospace, monospace" class="">foldl'</font> or <font face="monospace, monospace" class="">sort. </font><font face="arial, helvetica, sans-serif" class="">Almost nobody invokes </font><font face="monospace, monospace" class="">foldr</font><font face="arial, helvetica, sans-serif" class=""> from it</font>.</div><div class=""><br class=""></div><div class="">The "generalization and subsequent re-export deprecation" path breaks less code than the "leaving them monomorphic and breaking everyone who uses Data.List unqualified" path, even if it leads to an intermediate state that is a bit awkward, and doesn't lead easily to a final state where monomorphic versions of those combinators are available.</div><div class=""><br class=""></div><div class="">-Edward</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Feb 4, 2015 at 11:13 AM, Christopher Done <span dir="ltr" class=""><<a href="mailto:chrisdone@gmail.com" target="_blank" class="">chrisdone@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Looking at the generalizations in Data.List I find them pretty odd now when<br class="">
> I think about it. I'd expect Data.List functions to be monomorphic to<br class="">
> lists, just like I expect functions in Data.Map to be monomorphic to maps.<br class="">
> Now there might be generalized versions of these functions in e.g. the<br class="">
> Prelude, but generalizing Data.List means that I don't even have the<br class="">
> monomorphic versions available if I want to resolve ambiguity by using<br class="">
> them*.<br class="">
<br class="">
Sums up my feelings exactly. Data.Map, Data.List, etc. should be<br class="">
monomorphic. Adding generalized functions in Data.List is a little<br class="">
baffling.<br class="">
<div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
Libraries mailing list<br class="">
<a href="mailto:Libraries@haskell.org" class="">Libraries@haskell.org</a><br class="">
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank" class="">http://www.haskell.org/mailman/listinfo/libraries</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">Libraries mailing list<br class=""><a href="mailto:Libraries@haskell.org" class="">Libraries@haskell.org</a><br class="">http://www.haskell.org/mailman/listinfo/libraries<br class=""></div></blockquote></div><br class=""></div></div></body></html>