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

:

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 wrote:

On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt 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 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 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 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 mailto:ollie@ocharles.org.uk> wrote: > > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt > 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

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, 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 wrote:

On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt 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