Proposal: Add NonEmpty constructors to the Prelude

Fri Dec 30 05:08:46 UTC 2016

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.

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.

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.

-Edward

On Thu, Dec 29, 2016 at 12:57 PM, Andreas Abel <andreas.abel at ifi.lmu.de>
wrote:

> 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/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161230/ff410504/attachment-0001.html>