Proposal: Add NonEmpty constructors to the Prelude

[Henrik Nilsson]

Hi,

On 12/29/2016 12:48 PM, Andreas Abel wrote:
> What are the types and definitions of
>
>  > nonEmpty, (:|), and the type constructor NonEmpty.
>
> ?
>
> Must be something generic, overloaded, given the name...

Indeed, one would assume so, given the names.

But:

 > > What are the types and definitions of
 > >
 > >> nonEmpty, (:|), and the type constructor NonEmpty.
 > >
 > > ?
 >
 > See http://hackage.haskell.org/package/base-4.9.0.0/docs/
 > Data-List-NonEmpty.html

there is nothing generic at all about these:

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).

But these are really poor names for something this specific being made
available unqualified everywhere: there are lots of things that could
be called "NonEmpty" or "nonEmpty", and ":|" is a perfectly good
combinator name for other purposes.

So this addition would do little beside increasing the footprint of the
Prelude and causing issues clashes with code that happens to use these
names already.

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

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.

(And nothing new under the sun, either: people familiar
with Pascal or Ada will have had similar experiences with a
proliferation of integral types of various ranges. In simple cases,
very useful to ensure e.g. an array index is not out of bounds, but
does not go very far.)

Finally, why single out "non-empty" specifically as a
property worthy to keep track at the type level in the prelude?
Why not lists of finite length as well, for example?
That could help ensuring termination.

(Just to be clear: I am not proposing this. I am just saying
that I can't see how adding variations of existing types with
specific properties to the prelude possibly can result in
a principled design for a language like Haskell as it currently
stands.)

/Henrik





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.