Proposal: Add cons function to Data.List module
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 https://www.stackage.org/haddock/nightly-2019-09-11/vector-0.12.0.3/Data-Vec... I can't be the only that wants this function, right? ## Proposal Add cons :: x -> [x] -> [x] cons = (:) to Data.List
On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt <helmut.schmidt.4711@gmail.com> 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
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 <ollie@ocharles.org.uk> wrote:
On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt <helmut.schmidt.4711@gmail.com> 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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 <taylor@fausak.me
:
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 <ollie@ocharles.org.uk> wrote:
On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt <helmut.schmidt.4711@gmail.com> 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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 <taylor@fausak.me <mailto:taylor@fausak.me>>:
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 <ollie@ocharles.org.uk <mailto:ollie@ocharles.org.uk>> wrote: > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > <helmut.schmidt.4711@gmail.com <mailto:helmut.schmidt.4711@gmail.com>> 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 > Libraries@haskell.org <mailto:Libraries@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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 <andreas.abel@ifi.lmu.de> 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 <taylor@fausak.me <mailto:taylor@fausak.me>>:
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 <ollie@ocharles.org.uk <mailto:ollie@ocharles.org.uk>> wrote: > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > <helmut.schmidt.4711@gmail.com <mailto:helmut.schmidt.4711@gmail.com>> 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 > Libraries@haskell.org <mailto:Libraries@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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 <andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de>> 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 > <taylor@fausak.me <mailto:taylor@fausak.me> <mailto:taylor@fausak.me <mailto:taylor@fausak.me>>>: > > 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 > <ollie@ocharles.org.uk <mailto:ollie@ocharles.org.uk> <mailto:ollie@ocharles.org.uk <mailto:ollie@ocharles.org.uk>>> wrote: > > > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > > <helmut.schmidt.4711@gmail.com <mailto:helmut.schmidt.4711@gmail.com> > <mailto:helmut.schmidt.4711@gmail.com <mailto:helmut.schmidt.4711@gmail.com>>> 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 > > Libraries@haskell.org <mailto:Libraries@haskell.org> <mailto:Libraries@haskell.org <mailto:Libraries@haskell.org>> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org <mailto:Libraries@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ Libraries mailing list Libraries@haskell.org <mailto:Libraries@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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, <helmut.schmidt.4711@gmail.com> 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 < taylor@fausak.me>:
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 <ollie@ocharles.org.uk> wrote:
On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt <helmut.schmidt.4711@gmail.com> 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
participants (7)
-
Andreas Abel -
Bryan Richter -
David Feuer -
Helmut Schmidt -
Oliver Charles -
Taylor Fausak -
Tony Morris