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