<div dir="ltr"><div>Regardless of if NonEmpty should have been called NonEmptyList years ago when it was designed years ago (It was modeled on two existing libraries that took the NonEmpty name and at least one of those authors was vocally against the longer name, so we might never have been able to consolidate the implementation at all) and before it was brought into base, randomly recoloring the bikeshed at this point basically would just guarantee that all existing users are left with no migration path.<br></div><div><br>But your point on how annoyingly common the names are does make me shift to weakly -1 as to including them as part of an 8.6 migration story. Leaving them where they are in Data.List.NonEmpty and not exporting sconcat in the Prelude as an implementation detail for Semigroup like (<$), readPrec, readListPrec, log1p, etc. avoids clutter and breakage.<br></div><div><br></div><div>Heck, that way if you really want List somewhere in the name you can personally import Data.List.NonEmpty qualified or ignore it and sconcat entirely.<br></div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 29, 2016 at 12:57 PM, Andreas Abel <span dir="ltr"><<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since "nonEmpty" is a predicate that could apply any kind of collection, not just lists, I am strongly -1 on such a proposal.<br>
<br>
Similarly, "NonEmpty" misses a "List", it should be called "NonEmptyList".<span class="HOEnZb"><font color="#888888"><br>
<br>
--Andreas</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 29.12.2016 15:26, Henrik Nilsson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
On 12/29/2016 12:48 PM, Andreas Abel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What are the types and definitions of<br>
<br>
 > nonEmpty, (:|), and the type constructor NonEmpty.<br>
<br>
?<br>
<br>
Must be something generic, overloaded, given the name...<br>
</blockquote>
<br>
Indeed, one would assume so, given the names.<br>
<br>
But:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> What are the types and definitions of<br>
><br>
>> nonEmpty, (:|), and the type constructor NonEmpty.<br>
><br>
> ?<br>
<br>
See <a href="http://hackage.haskell.org/package/base-4.9.0.0/docs/" rel="noreferrer" target="_blank">http://hackage.haskell.org/pac<wbr>kage/base-4.9.0.0/docs/</a><br>
Data-List-NonEmpty.html<br>
</blockquote>
<br>
there is nothing generic at all about these:<br>
<br>
I am assuming that the idea is that these three definitions<br>
will be made available for unqualified use (while all other<br>
library functions for programming with non-empty lists would<br>
have to be imported explicitly from Data.List.NonEmpty, as<br>
currently is the case).<br>
<br>
But these are really poor names for something this specific being made<br>
available unqualified everywhere: there are lots of things that could<br>
be called "NonEmpty" or "nonEmpty", and ":|" is a perfectly good<br>
combinator name for other purposes.<br>
<br>
So this addition would do little beside increasing the footprint of the<br>
Prelude and causing issues clashes with code that happens to use these<br>
names already.<br>
<br>
To quote Yuras Shumovich from a related thread (Add readMaybe (and<br>
possibly readEither) to Prelude): "We should be careful with Prelude."<br>
<br>
Additionally, as is evidenced by the type signatures of the<br>
module NonEmpty, the utility of keeping track of non-empty lists at<br>
the type level in a language like Haskell is in general limited<br>
(which is not to say that it cannot be very useful sometimes).<br>
Even in a language with dependent types the approach (of integrating<br>
properties with data types) is not always smooth as it may lead to<br>
a proliferation of different related but distinct types which quickly<br>
becomes clunky. As far as I am aware, solving this conundrum is<br>
still an open research problem.<br>
<br>
(And nothing new under the sun, either: people familiar<br>
with Pascal or Ada will have had similar experiences with a<br>
proliferation of integral types of various ranges. In simple cases,<br>
very useful to ensure e.g. an array index is not out of bounds, but<br>
does not go very far.)<br>
<br>
Finally, why single out "non-empty" specifically as a<br>
property worthy to keep track at the type level in the prelude?<br>
Why not lists of finite length as well, for example?<br>
That could help ensuring termination.<br>
<br>
(Just to be clear: I am not proposing this. I am just saying<br>
that I can't see how adding variations of existing types with<br>
specific properties to the prelude possibly can result in<br>
a principled design for a language like Haskell as it currently<br>
stands.)<br>
<br>
/Henrik<br>
<br>
<br>
<br>
<br>
<br>
This message and any attachment are intended solely for the addressee<br>
and may contain confidential information. If you have received this<br>
message in error, please send it back to me, and immediately delete it.<br>
Please do not use, copy or disclose the information contained in this<br>
message or in any attachment.  Any views or opinions expressed by the<br>
author of this email do not necessarily reflect the views of the<br>
University of Nottingham.<br>
<br>
This message has been checked for viruses but the contents of an<br>
attachment may still contain software viruses which could damage your<br>
computer system, you are advised to perform your own checks. Email<br>
communications with the University of Nottingham may be monitored as<br>
permitted by UK legislation.<br>
<br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</blockquote>
<br>
<br></div></div><span class="im HOEnZb">
-- <br>
Andreas Abel  <><      Du bist der geliebte Mensch.<br>
<br>
Department of Computer Science and Engineering<br>
Chalmers and Gothenburg University, Sweden<br>
<br>
<a href="mailto:andreas.abel@gu.se" target="_blank">andreas.abel@gu.se</a><br>
<a href="http://www2.tcs.ifi.lmu.de/~abel/" rel="noreferrer" target="_blank">http://www2.tcs.ifi.lmu.de/~ab<wbr>el/</a><br></span><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>