Proposal: Add NonEmpty constructors to the Prelude

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: Add NonEmpty constructors to the Prelude

Yitzchak Gale
In continuation of Simon Jakobi's proposal for a small
incremental change to the Prelude to make it more
conducive to partial-function-free programming,

https://mail.haskell.org/pipermail/libraries/2016-December/027496.html

and after some encouragement from the community on reddit,
I propose adding the basic constructors of NonEmpty to
the Prelude: nonEmpty, (:|), and the type constructor NonEmpty.

In practice, users of NonEmpty will often still need a qualified
import of Data.List.NonEmpty. But having the constructors
available in the Prelude will make the use of NonEmpty more
common, and will make programming without partial functions
feel more natural and standard.

Note: This proposal is separate from Simon's and should not
interfere with the acceptance of Simon's. But it is related in
that it attempts to achieve the same goals.

Discussion period: Until the end of the discussion period of
Simon's proposal.

Thanks,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Haskell - Libraries mailing list
2016-12-28 20:39 GMT+01:00 Yitzchak Gale <[hidden email]>:
> I propose adding the basic constructors of NonEmpty to
> the Prelude: nonEmpty, (:|), and the type constructor NonEmpty.

+1

I'd still like to point out that all three names are exposed by
several other packages, mostly with different types:

* nonEmpty: https://www.stackage.org/lts-7.14/hoogle?q=nonEmpty&exact=on
* (:|): https://www.stackage.org/lts-7.14/hoogle?q=%3A%7C&exact=on
* NonEmpty: https://www.stackage.org/lts-7.14/hoogle?q=NonEmpty&exact=on
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Andreas Abel
In reply to this post by Yitzchak Gale
What are the types and definitions of

 > nonEmpty, (:|), and the type constructor NonEmpty.

?

Must be something generic, overloaded, given the name...

On 28.12.2016 20:39, Yitzchak Gale wrote:

> In continuation of Simon Jakobi's proposal for a small
> incremental change to the Prelude to make it more
> conducive to partial-function-free programming,
>
> https://mail.haskell.org/pipermail/libraries/2016-December/027496.html
>
> and after some encouragement from the community on reddit,
> I propose adding the basic constructors of NonEmpty to
> the Prelude: nonEmpty, (:|), and the type constructor NonEmpty.
>
> In practice, users of NonEmpty will often still need a qualified
> import of Data.List.NonEmpty. But having the constructors
> available in the Prelude will make the use of NonEmpty more
> common, and will make programming without partial functions
> feel more natural and standard.
>
> Note: This proposal is separate from Simon's and should not
> interfere with the acceptance of Simon's. But it is related in
> that it attempts to achieve the same goals.
>
> Discussion period: Until the end of the discussion period of
> Simon's proposal.
>
> Thanks,
> Yitz
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Haskell - Libraries mailing list
2016-12-29 13:48 GMT+01:00 Andreas Abel <[hidden email]>:
> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Henrik Nilsson-2
In reply to this post by Andreas Abel
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Edward Kmett-2
In reply to this post by Yitzchak Gale
I'm personally -1 on this proposal at this time. Adding these to the footprint of Prelude means everybody who has written any data type with a data constructor named :| breaks, every combinator named nonEmpty, NonEmpty type or class... so we shouldn't do this lightly.

That said, Semigroup is slated to become a superclass of Monoid in 8.6 and move into Prelude as part of the timeline on 


and Semigroup has sconcat as a member, which references NonEmpty. At that point the case becomes much stronger, and the need to decide how to handle sconcat for the Prelude acts as a forcing function for this decision.

On the other hand, we don't have many classes exported from Prelude partially, but we do have them: Functor (<$), Read (readPrec, readListPrec), Floating (log1p, expm1, etc.) come to mind as members we avoid exporting from Prelude.

So while there is precedent for continuing to hide "messy" implementation details, at that point the weight of simplicity of explanation may come down on the other side of the argument.

With all that in mind I'm -1 if we're talking about adding this in 8.4, but I'm largely neutral and maybe even weakly positive about it for 8.6 as part of the larger Semigroup migration and would be happy to accept either the hidden detail solution or a solution that dragged NonEmpty into base based on community feedback.

-Edward

On Wed, Dec 28, 2016 at 2:39 PM, Yitzchak Gale <[hidden email]> wrote:
In continuation of Simon Jakobi's proposal for a small
incremental change to the Prelude to make it more
conducive to partial-function-free programming,

https://mail.haskell.org/pipermail/libraries/2016-December/027496.html

and after some encouragement from the community on reddit,
I propose adding the basic constructors of NonEmpty to
the Prelude: nonEmpty, (:|), and the type constructor NonEmpty.

In practice, users of NonEmpty will often still need a qualified
import of Data.List.NonEmpty. But having the constructors
available in the Prelude will make the use of NonEmpty more
common, and will make programming without partial functions
feel more natural and standard.

Note: This proposal is separate from Simon's and should not
interfere with the acceptance of Simon's. But it is related in
that it attempts to achieve the same goals.

Discussion period: Until the end of the discussion period of
Simon's proposal.

Thanks,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Andreas Abel
In reply to this post by Henrik Nilsson-2
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
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Henning Thielemann
In reply to this post by Henrik Nilsson-2

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Ganesh Sittampalam
In reply to this post by Yitzchak Gale
-1 : I'm against this because NonEmpty is a special case of "lists with
at least n elements", and n=1 doesn't feel like a particuar sweet spot.
Once people are using NonEmpty everywhere, won't they need at least 2
elements when using tail to get a NonEmpty, etc?

On the flip side, the "group" functions do provide some argument in
favour, as the n=1 case is exactly the guarantee they provide for their
output.

On 28/12/2016 19:39, Yitzchak Gale wrote:

> In continuation of Simon Jakobi's proposal for a small
> incremental change to the Prelude to make it more
> conducive to partial-function-free programming,
>
> https://mail.haskell.org/pipermail/libraries/2016-December/027496.html
>
> and after some encouragement from the community on reddit,
> I propose adding the basic constructors of NonEmpty to
> the Prelude: nonEmpty, (:|), and the type constructor NonEmpty.
>
> In practice, users of NonEmpty will often still need a qualified
> import of Data.List.NonEmpty. But having the constructors
> available in the Prelude will make the use of NonEmpty more
> common, and will make programming without partial functions
> feel more natural and standard.
>
> Note: This proposal is separate from Simon's and should not
> interfere with the acceptance of Simon's. But it is related in
> that it attempts to achieve the same goals.
>
> Discussion period: Until the end of the discussion period of
> Simon's proposal.
>
> Thanks,
> Yitz
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Add NonEmpty constructors to the Prelude

Henning Thielemann

On Thu, 5 Jan 2017, Ganesh Sittampalam wrote:

> -1 : I'm against this because NonEmpty is a special case of "lists with
> at least n elements", and n=1 doesn't feel like a particuar sweet spot.
> Once people are using NonEmpty everywhere, won't they need at least 2
> elements when using tail to get a NonEmpty, etc?

Btw. my non-empty package provides a NonEmpty constructor that can be
nested, such that you can have lists with at least two elements.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...