Proposal: Add NonEmpty constructors to the Prelude

[Henning Thielemann]

On Thu, 29 Dec 2016, Henrik Nilsson wrote:

> I am assuming that the idea is that these three definitions
> will be made available for unqualified use (while all other
> library functions for programming with non-empty lists would
> have to be imported explicitly from Data.List.NonEmpty, as
> currently is the case).

This discussion and the one about readMaybe again boil down to the 
observation that many Haskell programmers seem to hate imports or the 
module system at all, that they invest a lot of work just to save a line 
of imports.

> To quote Yuras Shumovich from a related thread (Add readMaybe (and 
> possibly readEither) to Prelude): "We should be careful with Prelude."

+1

> Additionally, as is evidenced by the type signatures of the module 
> NonEmpty, the utility of keeping track of non-empty lists at the type 
> level in a language like Haskell is in general limited (which is not to 
> say that it cannot be very useful sometimes). Even in a language with 
> dependent types the approach (of integrating properties with data types) 
> is not always smooth as it may lead to a proliferation of different 
> related but distinct types which quickly becomes clunky. As far as I am 
> aware, solving this conundrum is still an open research problem.

I released the package non-negative 8 years ago and non-empty 4 years ago 
and could acquire some experience with them. My enthusiasm about 
non-negative declined considerably over time, since it did not catch bugs 
at compile but left me with errors at run-time where supposedly 
non-negative numbers turned out to be negative due to floating point 
issues. In contrast to that I am quite happy with non-empty. It allows me 
to document the non-emptiness of lists and Sets and Maps and makes me 
confident when using NonEmpty.head, NonEmpty.last, NonEmpty.maximum 
instead of their Prelude counterparts. Conversion to plain lists with 
NonEmpty.flatten is seldom enough to be painful. Only sometimes in a 
recursion it is difficult to get the types consistent, because a non-empty 
list as accumulator might become doubly non-empty temporarily.

I think that for non-negative numbers a tool like Liquid Haskell will be 
the better solution.