Proposal: Add cons function to Data.List module

[David Feuer]

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 at 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 at fausak.me <mailto:taylor at 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 at ocharles.org.uk <mailto:ollie at ocharles.org.uk>> wrote:
> >      >
> >      > On Wed, Sep 11, 2019 at 7:36 AM Helmut Schmidt
> >      > <helmut.schmidt.4711 at gmail.com
> >     <mailto:helmut.schmidt.4711 at 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 at haskell.org <mailto:Libraries at haskell.org>
> >      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> _______________________________________________
> 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/20190912/cfe436d5/attachment.html>