Proposal: Add NonEmpty constructors to the Prelude

[Andreas Abel]

Since "nonEmpty" is a predicate that could apply any kind of collection, 
not just lists, I am strongly -1 on such a proposal.

Similarly, "NonEmpty" misses a "List", it should be called "NonEmptyList".

--Andreas

On 29.12.2016 15:26, Henrik Nilsson wrote:
> 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.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/