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.