Proposal: Add cons function to Data.List module

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Add cons function to Data.List module

Helmut Schmidt

For more or less the same reasons that "singleton" was considered worth being added to Data.List I propose to add "cons" to Data.List as well.

## Motivation

Sometimes it is convenient to have a function to prepend an element to a list in pointless style code. But of the existing ways none of them are as clear as a separate monomorphic function.

- "( : )" is subjectively ugly
- "(\x xs -> x : xs)" is syntactically noisy

Purescript also has a "Cons" function so why can't we have one too?

We already have "Data.List.uncons" and so for symmetry one would also expect to find "Data.List.cons".

Many sequence like APIs have a "cons" function such as


I can't be the only that wants this function, right?

## Proposal

Add

cons :: x -> [x] -> [x]
cons = (:)

to Data.List



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

Re: Proposal: Add cons function to Data.List module

Oliver Charles-3
On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
<[hidden email]> wrote:

> I can't be the only that wants this function, right?

You're not the only one! I would also like this function. In fact,
only yesterday I found myself writing

  ( x : ) <$> recurse xs

I would have preferred

  cons x <$> recurse xs

+1 to adding  cons :: x -> [x] -> [x]  to  Data.List.

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

Re: Proposal: Add cons function to Data.List module

Taylor Fausak
I suspect this proposal was not made in good faith. I feel like it was meant to make fun of my list singleton proposal.

In spite of that, I am in favor of this proposal. One of the (very minor!) problems with lists in Haskell is that they can’t be documented with Haddock because they’re part of the syntax. For example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you won’t find the venerable list constructor. You will find `cons` from the `extra` package, which I think suggests that this proposal is a good idea.

+1

> On Sep 11, 2019, at 4:13 AM, Oliver Charles <[hidden email]> wrote:
>
> On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
> <[hidden email]> wrote:
>
>> I can't be the only that wants this function, right?
>
> You're not the only one! I would also like this function. In fact,
> only yesterday I found myself writing
>
>  ( x : ) <$> recurse xs
>
> I would have preferred
>
>  cons x <$> recurse xs
>
> +1 to adding  cons :: x -> [x] -> [x]  to  Data.List.
>
> Ollie
> _______________________________________________
> 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
|

Re: Proposal: Add cons function to Data.List module

Helmut Schmidt
Taylor,

Is it really necessary for you to be so rude? I can assure you that my proposal has been made in the same good faith as your proposal which inspired mine.

Besides that unnecessary snark you do make an excellent point regarding the poor discoverability of the list constructor which I imagine must cause a lot of confusion among newcomers.Thank you for keeping an open mind!



Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak <[hidden email]>:
I suspect this proposal was not made in good faith. I feel like it was meant to make fun of my list singleton proposal.

In spite of that, I am in favor of this proposal. One of the (very minor!) problems with lists in Haskell is that they can’t be documented with Haddock because they’re part of the syntax. For example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you won’t find the venerable list constructor. You will find `cons` from the `extra` package, which I think suggests that this proposal is a good idea.

+1

> On Sep 11, 2019, at 4:13 AM, Oliver Charles <[hidden email]> wrote:
>
> On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
> <[hidden email]> wrote:
>
>> I can't be the only that wants this function, right?
>
> You're not the only one! I would also like this function. In fact,
> only yesterday I found myself writing
>
>  ( x : ) <$> recurse xs
>
> I would have preferred
>
>  cons x <$> recurse xs
>
> +1 to adding  cons :: x -> [x] -> [x]  to  Data.List.
>
> Ollie
> _______________________________________________
> 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
|

Re: Proposal: Add cons function to Data.List module

Andreas Abel
I think this proposal was be stronger if it would lay out the bigger
picture, i.e., directions towards a unified interface to sequence-like
collections.

-1 in its current form.

On 2019-09-11 16:32, Helmut Schmidt wrote:

> Taylor,
>
> Is it really necessary for you to be so rude? I can assure you that my
> proposal has been made in the same good faith as your proposal which
> inspired mine.
>
> Besides that unnecessary snark you do make an excellent point regarding
> the poor discoverability of the list constructor which I imagine must
> cause a lot of confusion among newcomers.Thank you for keeping an open mind!
>
>
>
> Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak
> <[hidden email] <mailto:[hidden email]>>:
>
>     I suspect this proposal was not made in good faith. I feel like it
>     was meant to make fun of my list singleton proposal.
>
>     In spite of that, I am in favor of this proposal. One of the (very
>     minor!) problems with lists in Haskell is that they can’t be
>     documented with Haddock because they’re part of the syntax. For
>     example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you
>     won’t find the venerable list constructor. You will find `cons` from
>     the `extra` package, which I think suggests that this proposal is a
>     good idea.
>
>     +1
>
>      > On Sep 11, 2019, at 4:13 AM, Oliver Charles
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >
>      > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
>      > <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >
>      >> I can't be the only that wants this function, right?
>      >
>      > You're not the only one! I would also like this function. In fact,
>      > only yesterday I found myself writing
>      >
>      >  ( x : ) <$> recurse xs
>      >
>      > I would have preferred
>      >
>      >  cons x <$> recurse xs
>      >
>      > +1 to adding  cons :: x -> [x] -> [x]  to  Data.List.
>      >
>      > Ollie
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[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
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add cons function to Data.List module

Bryan Richter-2
In reply to this post by Helmut Schmidt
I had the same reaction as Taylor, since Helmut referred to the singleton proposal as "pointless" in the thread on "on". Then I stopped to wonder if there was a mixup. "Point-free" style, which cons and singleton both facilitate, is sometimes called "pointless" style, but usually only as a joke. It's wordplay.

Since Helmut writes perfectly good English, I had assumed the wordplay was intentional, which made me suspicious of the nature of this proposal. But from over here on my little digital device, it is hard to know for sure.

Either way, I think the plan to make Data.List qualified-by-default is great, and having a uniform abstraction over list-like things is also good. I look forward to seeing more use of backpack to take advantage of such abstractions.

I suggest that the haddocks for Data.List.cons clearly state that it is just a synonym for the list constructor, so we get a built-in "teachable moment".


On Wed, 11 Sep 2019, 17.33 Helmut Schmidt, <[hidden email]> wrote:
Taylor,

Is it really necessary for you to be so rude? I can assure you that my proposal has been made in the same good faith as your proposal which inspired mine.

Besides that unnecessary snark you do make an excellent point regarding the poor discoverability of the list constructor which I imagine must cause a lot of confusion among newcomers.Thank you for keeping an open mind!



Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak <[hidden email]>:
I suspect this proposal was not made in good faith. I feel like it was meant to make fun of my list singleton proposal.

In spite of that, I am in favor of this proposal. One of the (very minor!) problems with lists in Haskell is that they can’t be documented with Haddock because they’re part of the syntax. For example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you won’t find the venerable list constructor. You will find `cons` from the `extra` package, which I think suggests that this proposal is a good idea.

+1

> On Sep 11, 2019, at 4:13 AM, Oliver Charles <[hidden email]> wrote:
>
> On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
> <[hidden email]> wrote:
>
>> I can't be the only that wants this function, right?
>
> You're not the only one! I would also like this function. In fact,
> only yesterday I found myself writing
>
>  ( x : ) <$> recurse xs
>
> I would have preferred
>
>  cons x <$> recurse xs
>
> +1 to adding  cons :: x -> [x] -> [x]  to  Data.List.
>
> Ollie
> _______________________________________________
> 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

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

Re: Proposal: Add cons function to Data.List module

David Feuer
In reply to this post by Andreas Abel
I think Michael Snoyman did a good job of starting that conversation with his IsSequence class in mono-traversable. I don't agree with a lot of the specific design decisions he's made, but I think we should definitely think about previous experience in that space.

Personally, I prefer an MPTC-based interface for the monomorphic stuff. This is mostly a matter of taste, of course. One important idea, of course, is that of a free monoid:

type family Elem xs

class e ~ Elem c => MonoFoldable e c where
  mfoldMap :: Monoid m => (e -> m) -> c -> m

class (MonoFoldable e c, Monoid c) => MonoSequence e c where
  mSingleton :: e -> c
  -- All other methods can be optional

class (forall e. Monoid (t e)) => Monoid1 t
instance (forall e. Monoid (t e)) => Monoid1 t

class (Traversable t, Monoid1 t) => Sequence t where
  singleton :: e -> t e
  -- All other methods can be optional

On Thu, Sep 12, 2019, 10:42 AM Andreas Abel <[hidden email]> wrote:
I think this proposal was be stronger if it would lay out the bigger
picture, i.e., directions towards a unified interface to sequence-like
collections.

-1 in its current form.

On 2019-09-11 16:32, Helmut Schmidt wrote:
> Taylor,
>
> Is it really necessary for you to be so rude? I can assure you that my
> proposal has been made in the same good faith as your proposal which
> inspired mine.
>
> Besides that unnecessary snark you do make an excellent point regarding
> the poor discoverability of the list constructor which I imagine must
> cause a lot of confusion among newcomers.Thank you for keeping an open mind!
>
>
>
> Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak
> <[hidden email] <mailto:[hidden email]>>:
>
>     I suspect this proposal was not made in good faith. I feel like it
>     was meant to make fun of my list singleton proposal.
>
>     In spite of that, I am in favor of this proposal. One of the (very
>     minor!) problems with lists in Haskell is that they can’t be
>     documented with Haddock because they’re part of the syntax. For
>     example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you
>     won’t find the venerable list constructor. You will find `cons` from
>     the `extra` package, which I think suggests that this proposal is a
>     good idea.
>
>     +1
>
>      > On Sep 11, 2019, at 4:13 AM, Oliver Charles
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >
>      > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
>      > <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >
>      >> I can't be the only that wants this function, right?
>      >
>      > You're not the only one! I would also like this function. In fact,
>      > only yesterday I found myself writing
>      >
>      >  ( x : ) <$> recurse xs
>      >
>      > I would have preferred
>      >
>      >  cons x <$> recurse xs
>      >
>      > +1 to adding  cons :: x -> [x] -> [x]  to  Data.List.
>      >
>      > Ollie
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[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
>
_______________________________________________
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
|

Re: Proposal: Add cons function to Data.List module

Tony Morris-4

If we're looking at things like this, have you seen the At, Cons and Empty type-classes in lens?

On 13/9/19 1:13 am, David Feuer wrote:
I think Michael Snoyman did a good job of starting that conversation with his IsSequence class in mono-traversable. I don't agree with a lot of the specific design decisions he's made, but I think we should definitely think about previous experience in that space.

Personally, I prefer an MPTC-based interface for the monomorphic stuff. This is mostly a matter of taste, of course. One important idea, of course, is that of a free monoid:

type family Elem xs

class e ~ Elem c => MonoFoldable e c where
  mfoldMap :: Monoid m => (e -> m) -> c -> m

class (MonoFoldable e c, Monoid c) => MonoSequence e c where
  mSingleton :: e -> c
  -- All other methods can be optional

class (forall e. Monoid (t e)) => Monoid1 t
instance (forall e. Monoid (t e)) => Monoid1 t

class (Traversable t, Monoid1 t) => Sequence t where
  singleton :: e -> t e
  -- All other methods can be optional

On Thu, Sep 12, 2019, 10:42 AM Andreas Abel <[hidden email]> wrote:
I think this proposal was be stronger if it would lay out the bigger
picture, i.e., directions towards a unified interface to sequence-like
collections.

-1 in its current form.

On 2019-09-11 16:32, Helmut Schmidt wrote:
> Taylor,
>
> Is it really necessary for you to be so rude? I can assure you that my
> proposal has been made in the same good faith as your proposal which
> inspired mine.
>
> Besides that unnecessary snark you do make an excellent point regarding
> the poor discoverability of the list constructor which I imagine must
> cause a lot of confusion among newcomers.Thank you for keeping an open mind!
>
>
>
> Am Mi., 11. Sept. 2019 um 11:21 Uhr schrieb Taylor Fausak
> <[hidden email] <mailto:[hidden email]>>:
>
>     I suspect this proposal was not made in good faith. I feel like it
>     was meant to make fun of my list singleton proposal.
>
>     In spite of that, I am in favor of this proposal. One of the (very
>     minor!) problems with lists in Haskell is that they can’t be
>     documented with Haddock because they’re part of the syntax. For
>     example, if you search Hoogle for `(:)` or `a -> [a] -> [a]` you
>     won’t find the venerable list constructor. You will find `cons` from
>     the `extra` package, which I think suggests that this proposal is a
>     good idea.
>
>     +1
>
>      > On Sep 11, 2019, at 4:13 AM, Oliver Charles
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >
>      > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
>      > <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >
>      >> I can't be the only that wants this function, right?
>      >
>      > You're not the only one! I would also like this function. In fact,
>      > only yesterday I found myself writing
>      >
>      >  ( x : ) <$> recurse xs
>      >
>      > I would have preferred
>      >
>      >  cons x <$> recurse xs
>      >
>      > +1 to adding  cons :: x -> [x] -> [x]  to  Data.List.
>      >
>      > Ollie
>      > _______________________________________________
>      > Libraries mailing list
>      > [hidden email] <mailto:[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
>
_______________________________________________
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

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

signature.asc (499 bytes) Download Attachment