With the recent discussion around the addition of 'intersection' to containers,
I think it might be a good time to re-open the discussion surrounding adding 'Foldable1' to base. For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts folds over non-empty containers. Alternatively, it can be seen as a method of combining together the elements of a container using a semigroup. The contents of this class have been discussed previously (See [1,2]), and the version presented in this proposal is taken from [1]. class Foldable t => Foldable1 t where {-# MINIMAL foldMap1 | foldr1map #-} fold1 :: Semigroup m => t m -> m -- the defining member, like foldMap but only asking for Semigroup foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- strict foldMap1, cf foldMap' foldMap1' :: Semigroup m => (a -> m) -> t a -> m -- analogue of toList toNonEmpty :: t a -> NonEmpty a -- left&right, strict&non-strict folds foldr1 :: (a -> a -> a) -> t a -> a foldr1' :: (a -> a -> a) -> t a -> a foldl1 :: (a -> a -> a) -> t a -> a foldl1' :: (a -> a -> a) -> t a -> a -- these can have efficient implementation for NonEmptySet maximum1 :: Ord a => t a -> a minimum1 :: Ord a => t a -> a -- head1 have efficient implementation for NonEmpty and Tree -- last1 for symmetry head1 :: t a -> a last1 :: t a -> a -- fold variants with premap. -- Without this map, we cannot implement foldl using foldr etc. foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b This has a couple of benefits. On the practical side, we can provide total alternatives to existing partial functions (IE: 'foldr1' and friends). It also enables us to fold over containers using a semigroup instance, which comes up suprisingly often. Naming: -------------------------------------------------------------------------------- Historically, the biggest source of controversy with this proposal has been over the name. The class currently exists in semigroupoids [3] under the name 'Foldable1', though there was some discussion around renaming it to 'SemiFoldable' [4]. However, if we keep the name unchanged, it makes the migration path nice and straightforward, and the possible name conflict with Data.Functor.Classes seems unlikely. Migration: -------------------------------------------------------------------------------- If we decide to go with 'Foldable1' as the name, we should be able to perform this change with 0 breakage. References: [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 [4] https://github.com/ekmett/semigroupoids/issues/26 _______________________________________________ Libraries mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries |
That seems rather large to me, and some of those methods don't have much if any historical usage. I'd recommend starting with a slightly smaller class. It's always easier to add more later than to remove. My suggestion:
foldMap1 :: Semigroup m => (a -> m) -> t a -> m foldMap1' :: Semigroup m => (a -> m) -> t a -> m toNonEmpty :: t a -> NonEmpty a The rest can be exported as functions, rather than methods, to begin with. On Thu, Dec 10, 2020, 1:38 AM Reed Mullanix <[hidden email]> wrote: With the recent discussion around the addition of 'intersection' to containers, _______________________________________________ Libraries mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries |
Seems reasonable to me! I definitely agree that we ought to add a
strict foldMap1 to the version found in semigroupoids. On Wed, Dec 9, 2020 at 11:08 PM David Feuer <[hidden email]> wrote: > > That seems rather large to me, and some of those methods don't have much if any historical usage. I'd recommend starting with a slightly smaller class. It's always easier to add more later than to remove. My suggestion: > > foldMap1 :: Semigroup m => (a -> m) -> t a -> m > > foldMap1' :: Semigroup m => (a -> m) -> t a -> m > > toNonEmpty :: t a -> NonEmpty a > > The rest can be exported as functions, rather than methods, to begin with. > > On Thu, Dec 10, 2020, 1:38 AM Reed Mullanix <[hidden email]> wrote: >> >> With the recent discussion around the addition of 'intersection' to containers, >> I think it might be a good time to re-open the discussion surrounding adding >> 'Foldable1' to base. >> >> For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts >> folds over non-empty containers. Alternatively, it can be seen as a method >> of combining together the elements of a container using a semigroup. >> The contents of this class have been discussed previously (See [1,2]), >> and the version presented in this proposal is taken from [1]. >> >> class Foldable t => Foldable1 t where >> {-# MINIMAL foldMap1 | foldr1map #-} >> >> fold1 :: Semigroup m => t m -> m >> >> -- the defining member, like foldMap but only asking for Semigroup >> foldMap1 :: Semigroup m => (a -> m) -> t a -> m >> >> -- strict foldMap1, cf foldMap' >> foldMap1' :: Semigroup m => (a -> m) -> t a -> m >> >> -- analogue of toList >> toNonEmpty :: t a -> NonEmpty a >> >> -- left&right, strict&non-strict folds >> foldr1 :: (a -> a -> a) -> t a -> a >> foldr1' :: (a -> a -> a) -> t a -> a >> foldl1 :: (a -> a -> a) -> t a -> a >> foldl1' :: (a -> a -> a) -> t a -> a >> >> -- these can have efficient implementation for NonEmptySet >> maximum1 :: Ord a => t a -> a >> minimum1 :: Ord a => t a -> a >> >> -- head1 have efficient implementation for NonEmpty and Tree >> -- last1 for symmetry >> head1 :: t a -> a >> last1 :: t a -> a >> >> -- fold variants with premap. >> -- Without this map, we cannot implement foldl using foldr etc. >> foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b >> foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b >> foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b >> foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b >> >> >> This has a couple of benefits. On the practical side, we can provide >> total alternatives >> to existing partial functions (IE: 'foldr1' and friends). It also >> enables us to fold >> over containers using a semigroup instance, which comes up suprisingly often. >> >> Naming: >> -------------------------------------------------------------------------------- >> Historically, the biggest source of controversy with this proposal has >> been over the >> name. The class currently exists in semigroupoids [3] under the name >> 'Foldable1', though >> there was some discussion around renaming it to 'SemiFoldable' [4]. >> However, if we keep >> the name unchanged, it makes the migration path nice and >> straightforward, and the possible >> name conflict with Data.Functor.Classes seems unlikely. >> >> Migration: >> -------------------------------------------------------------------------------- >> If we decide to go with 'Foldable1' as the name, we should be able to >> perform this change with >> 0 breakage. >> >> References: >> [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html >> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 >> [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 >> [4] https://github.com/ekmett/semigroupoids/issues/26 >> _______________________________________________ >> 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 |
+1
Am Do., 10. Dez. 2020 um 08:20 Uhr schrieb Reed Mullanix <[hidden email]>: > > Seems reasonable to me! I definitely agree that we ought to add a > strict foldMap1 to the version found in semigroupoids. > > On Wed, Dec 9, 2020 at 11:08 PM David Feuer <[hidden email]> wrote: > > > > That seems rather large to me, and some of those methods don't have much if any historical usage. I'd recommend starting with a slightly smaller class. It's always easier to add more later than to remove. My suggestion: > > > > foldMap1 :: Semigroup m => (a -> m) -> t a -> m > > > > foldMap1' :: Semigroup m => (a -> m) -> t a -> m > > > > toNonEmpty :: t a -> NonEmpty a > > > > The rest can be exported as functions, rather than methods, to begin with. > > > > On Thu, Dec 10, 2020, 1:38 AM Reed Mullanix <[hidden email]> wrote: > >> > >> With the recent discussion around the addition of 'intersection' to containers, > >> I think it might be a good time to re-open the discussion surrounding adding > >> 'Foldable1' to base. > >> > >> For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts > >> folds over non-empty containers. Alternatively, it can be seen as a method > >> of combining together the elements of a container using a semigroup. > >> The contents of this class have been discussed previously (See [1,2]), > >> and the version presented in this proposal is taken from [1]. > >> > >> class Foldable t => Foldable1 t where > >> {-# MINIMAL foldMap1 | foldr1map #-} > >> > >> fold1 :: Semigroup m => t m -> m > >> > >> -- the defining member, like foldMap but only asking for Semigroup > >> foldMap1 :: Semigroup m => (a -> m) -> t a -> m > >> > >> -- strict foldMap1, cf foldMap' > >> foldMap1' :: Semigroup m => (a -> m) -> t a -> m > >> > >> -- analogue of toList > >> toNonEmpty :: t a -> NonEmpty a > >> > >> -- left&right, strict&non-strict folds > >> foldr1 :: (a -> a -> a) -> t a -> a > >> foldr1' :: (a -> a -> a) -> t a -> a > >> foldl1 :: (a -> a -> a) -> t a -> a > >> foldl1' :: (a -> a -> a) -> t a -> a > >> > >> -- these can have efficient implementation for NonEmptySet > >> maximum1 :: Ord a => t a -> a > >> minimum1 :: Ord a => t a -> a > >> > >> -- head1 have efficient implementation for NonEmpty and Tree > >> -- last1 for symmetry > >> head1 :: t a -> a > >> last1 :: t a -> a > >> > >> -- fold variants with premap. > >> -- Without this map, we cannot implement foldl using foldr etc. > >> foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b > >> foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b > >> foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b > >> foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b > >> > >> > >> This has a couple of benefits. On the practical side, we can provide > >> total alternatives > >> to existing partial functions (IE: 'foldr1' and friends). It also > >> enables us to fold > >> over containers using a semigroup instance, which comes up suprisingly often. > >> > >> Naming: > >> -------------------------------------------------------------------------------- > >> Historically, the biggest source of controversy with this proposal has > >> been over the > >> name. The class currently exists in semigroupoids [3] under the name > >> 'Foldable1', though > >> there was some discussion around renaming it to 'SemiFoldable' [4]. > >> However, if we keep > >> the name unchanged, it makes the migration path nice and > >> straightforward, and the possible > >> name conflict with Data.Functor.Classes seems unlikely. > >> > >> Migration: > >> -------------------------------------------------------------------------------- > >> If we decide to go with 'Foldable1' as the name, we should be able to > >> perform this change with > >> 0 breakage. > >> > >> References: > >> [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html > >> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 > >> [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 > >> [4] https://github.com/ekmett/semigroupoids/issues/26 > >> _______________________________________________ > >> 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 |
+1
_______________________________________________ Libraries mailing list [hidden email] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries |
In reply to this post by Reed Mullanix
Delete head1 and last1 and you'll get my +1.
(they are better written as optics, when we also get Apply into base) On 12/10/20 4:37 PM, Reed Mullanix wrote: > With the recent discussion around the addition of 'intersection' to containers, > I think it might be a good time to re-open the discussion surrounding adding > 'Foldable1' to base. > > For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts > folds over non-empty containers. Alternatively, it can be seen as a method > of combining together the elements of a container using a semigroup. > The contents of this class have been discussed previously (See [1,2]), > and the version presented in this proposal is taken from [1]. > > class Foldable t => Foldable1 t where > {-# MINIMAL foldMap1 | foldr1map #-} > > fold1 :: Semigroup m => t m -> m > > -- the defining member, like foldMap but only asking for Semigroup > foldMap1 :: Semigroup m => (a -> m) -> t a -> m > > -- strict foldMap1, cf foldMap' > foldMap1' :: Semigroup m => (a -> m) -> t a -> m > > -- analogue of toList > toNonEmpty :: t a -> NonEmpty a > > -- left&right, strict&non-strict folds > foldr1 :: (a -> a -> a) -> t a -> a > foldr1' :: (a -> a -> a) -> t a -> a > foldl1 :: (a -> a -> a) -> t a -> a > foldl1' :: (a -> a -> a) -> t a -> a > > -- these can have efficient implementation for NonEmptySet > maximum1 :: Ord a => t a -> a > minimum1 :: Ord a => t a -> a > > -- head1 have efficient implementation for NonEmpty and Tree > -- last1 for symmetry > head1 :: t a -> a > last1 :: t a -> a > > -- fold variants with premap. > -- Without this map, we cannot implement foldl using foldr etc. > foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b > foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b > foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b > foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b > > > This has a couple of benefits. On the practical side, we can provide > total alternatives > to existing partial functions (IE: 'foldr1' and friends). It also > enables us to fold > over containers using a semigroup instance, which comes up suprisingly often. > > Naming: > -------------------------------------------------------------------------------- > Historically, the biggest source of controversy with this proposal has > been over the > name. The class currently exists in semigroupoids [3] under the name > 'Foldable1', though > there was some discussion around renaming it to 'SemiFoldable' [4]. > However, if we keep > the name unchanged, it makes the migration path nice and > straightforward, and the possible > name conflict with Data.Functor.Classes seems unlikely. > > Migration: > -------------------------------------------------------------------------------- > If we decide to go with 'Foldable1' as the name, we should be able to > perform this change with > 0 breakage. > > References: > [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 > [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 > [4] https://github.com/ekmett/semigroupoids/issues/26 > _______________________________________________ > 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 |
I like David's more conservative class size.
I would prefer to see the semigroupoids classes renamed [1] before they get added to base, since it's much harder to rename them once they're there. However, it's not clear to me that there's the required will to move forward with such a gargantuan renaming effort (semigroupoids is depended on directly and transitively by a lot of hackage). There was a recent attempt that didn't gain traction [2]. I would also prefer that the renaming and the move to base are two discrete steps -- not combined, since that would make the migration awkward and unpleasant (migrating to a differently-named class from a different package). I want to see the spirit of this happen, but overall I'm -1 on this proposal at this time. [1] https://github.com/ekmett/semigroupoids/issues/26 [2] https://github.com/ekmett/semigroupoids/pull/90 Cheers, George On Fri, 11 Dec 2020 at 22:37, Tony Morris <[hidden email]> wrote: > > Delete head1 and last1 and you'll get my +1. > > (they are better written as optics, when we also get Apply into base) > > On 12/10/20 4:37 PM, Reed Mullanix wrote: > > With the recent discussion around the addition of 'intersection' to containers, > > I think it might be a good time to re-open the discussion surrounding adding > > 'Foldable1' to base. > > > > For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts > > folds over non-empty containers. Alternatively, it can be seen as a method > > of combining together the elements of a container using a semigroup. > > The contents of this class have been discussed previously (See [1,2]), > > and the version presented in this proposal is taken from [1]. > > > > class Foldable t => Foldable1 t where > > {-# MINIMAL foldMap1 | foldr1map #-} > > > > fold1 :: Semigroup m => t m -> m > > > > -- the defining member, like foldMap but only asking for Semigroup > > foldMap1 :: Semigroup m => (a -> m) -> t a -> m > > > > -- strict foldMap1, cf foldMap' > > foldMap1' :: Semigroup m => (a -> m) -> t a -> m > > > > -- analogue of toList > > toNonEmpty :: t a -> NonEmpty a > > > > -- left&right, strict&non-strict folds > > foldr1 :: (a -> a -> a) -> t a -> a > > foldr1' :: (a -> a -> a) -> t a -> a > > foldl1 :: (a -> a -> a) -> t a -> a > > foldl1' :: (a -> a -> a) -> t a -> a > > > > -- these can have efficient implementation for NonEmptySet > > maximum1 :: Ord a => t a -> a > > minimum1 :: Ord a => t a -> a > > > > -- head1 have efficient implementation for NonEmpty and Tree > > -- last1 for symmetry > > head1 :: t a -> a > > last1 :: t a -> a > > > > -- fold variants with premap. > > -- Without this map, we cannot implement foldl using foldr etc. > > foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b > > foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b > > foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b > > foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b > > > > > > This has a couple of benefits. On the practical side, we can provide > > total alternatives > > to existing partial functions (IE: 'foldr1' and friends). It also > > enables us to fold > > over containers using a semigroup instance, which comes up suprisingly often. > > > > Naming: > > -------------------------------------------------------------------------------- > > Historically, the biggest source of controversy with this proposal has > > been over the > > name. The class currently exists in semigroupoids [3] under the name > > 'Foldable1', though > > there was some discussion around renaming it to 'SemiFoldable' [4]. > > However, if we keep > > the name unchanged, it makes the migration path nice and > > straightforward, and the possible > > name conflict with Data.Functor.Classes seems unlikely. > > > > Migration: > > -------------------------------------------------------------------------------- > > If we decide to go with 'Foldable1' as the name, we should be able to > > perform this change with > > 0 breakage. > > > > References: > > [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html > > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 > > [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 > > [4] https://github.com/ekmett/semigroupoids/issues/26 > > _______________________________________________ > > 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 |
The conservative class size is not optimal.
One needs at least to have foldrMap-like function. See https://github.com/ekmett/semigroupoids/issues/77 I think that renaming *and* moving to base is better done in one step, as then ecosystem would need to adjust once. A clean approach to migration, which I'd recommend, is to have a (new) compatibility package, because semigroupoids is too heavy, folks don't want to depend on it, even semigroups is heavy for some/ Let's tentatively call it foldable1. Then new base would have the exact same modules as foldable1. And then semigroupoids may at its own pace migrate to use base/foldable1 and the rest of ecosystem would follow. Given that Foldable1 isn't terribly spread class (yet), I don't see that more complicated that what regular major base updates are. There is another reason to have separate package: Bifoldable1, which I argue should be moved to base as well. I think this all is mentioned in my proposal https://oleg.fi/foldable1-proposal3.html I (and also Edward, IIUC) call for CLC to make the choice of naming. The proposal above have three options, I hope one of them fits. - Oleg On 3.1.2021 13.01, George Wilson wrote: > I like David's more conservative class size. > > I would prefer to see the semigroupoids classes renamed [1] before > they get added to base, since it's much harder to rename them once > they're there. However, it's not clear to me that there's the required > will to move forward with such a gargantuan renaming effort > (semigroupoids is depended on directly and transitively by a lot of > hackage). There was a recent attempt that didn't gain traction [2]. I > would also prefer that the renaming and the move to base are two > discrete steps -- not combined, since that would make the migration > awkward and unpleasant (migrating to a differently-named class from a > different package). > > I want to see the spirit of this happen, but overall I'm -1 on this > proposal at this time. > > [1] https://github.com/ekmett/semigroupoids/issues/26 > [2] https://github.com/ekmett/semigroupoids/pull/90 > > Cheers, > George > > > On Fri, 11 Dec 2020 at 22:37, Tony Morris <[hidden email]> wrote: >> Delete head1 and last1 and you'll get my +1. >> >> (they are better written as optics, when we also get Apply into base) >> >> On 12/10/20 4:37 PM, Reed Mullanix wrote: >>> With the recent discussion around the addition of 'intersection' to containers, >>> I think it might be a good time to re-open the discussion surrounding adding >>> 'Foldable1' to base. >>> >>> For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts >>> folds over non-empty containers. Alternatively, it can be seen as a method >>> of combining together the elements of a container using a semigroup. >>> The contents of this class have been discussed previously (See [1,2]), >>> and the version presented in this proposal is taken from [1]. >>> >>> class Foldable t => Foldable1 t where >>> {-# MINIMAL foldMap1 | foldr1map #-} >>> >>> fold1 :: Semigroup m => t m -> m >>> >>> -- the defining member, like foldMap but only asking for Semigroup >>> foldMap1 :: Semigroup m => (a -> m) -> t a -> m >>> >>> -- strict foldMap1, cf foldMap' >>> foldMap1' :: Semigroup m => (a -> m) -> t a -> m >>> >>> -- analogue of toList >>> toNonEmpty :: t a -> NonEmpty a >>> >>> -- left&right, strict&non-strict folds >>> foldr1 :: (a -> a -> a) -> t a -> a >>> foldr1' :: (a -> a -> a) -> t a -> a >>> foldl1 :: (a -> a -> a) -> t a -> a >>> foldl1' :: (a -> a -> a) -> t a -> a >>> >>> -- these can have efficient implementation for NonEmptySet >>> maximum1 :: Ord a => t a -> a >>> minimum1 :: Ord a => t a -> a >>> >>> -- head1 have efficient implementation for NonEmpty and Tree >>> -- last1 for symmetry >>> head1 :: t a -> a >>> last1 :: t a -> a >>> >>> -- fold variants with premap. >>> -- Without this map, we cannot implement foldl using foldr etc. >>> foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b >>> foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b >>> foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b >>> foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b >>> >>> >>> This has a couple of benefits. On the practical side, we can provide >>> total alternatives >>> to existing partial functions (IE: 'foldr1' and friends). It also >>> enables us to fold >>> over containers using a semigroup instance, which comes up suprisingly often. >>> >>> Naming: >>> -------------------------------------------------------------------------------- >>> Historically, the biggest source of controversy with this proposal has >>> been over the >>> name. The class currently exists in semigroupoids [3] under the name >>> 'Foldable1', though >>> there was some discussion around renaming it to 'SemiFoldable' [4]. >>> However, if we keep >>> the name unchanged, it makes the migration path nice and >>> straightforward, and the possible >>> name conflict with Data.Functor.Classes seems unlikely. >>> >>> Migration: >>> -------------------------------------------------------------------------------- >>> If we decide to go with 'Foldable1' as the name, we should be able to >>> perform this change with >>> 0 breakage. >>> >>> References: >>> [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html >>> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 >>> [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup-Foldable.html#t:Foldable1 >>> [4] https://github.com/ekmett/semigroupoids/issues/26 >>> _______________________________________________ >>> 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 |
Free forum by Nabble | Edit this page |