Re: Proposal: Add Foldable1 from 'semigroupoids' to base

Semicomonad Semibifoldable Semibitraversable There is discussion about whether to rename some or all of the combinators to a semi- prefix. There is also a longstanding discussion about what to do for the API surface of Semifoldable, etc. Can it stay with the simplistic model it has now or does it need elaboration like the Foldable API did. If I'm going to ask users to make a major version bump, I'd like to resolve this question at the same time to minimize thrashing and rework. I'd like to get all of those things resolved in semigroupoids before it gets folded into base. Because once it is in base, that is a hell of a lot harder to deal with. Fixing things in a third-party package with a long support window, people can just bump the bounds on their semigroupoids dependency. Fixing them later on in base in a way that requires CPP to bridge the gap? You now lock users into CPP and into dealing with both sets of names until the old version of base drops out of whatever their arbitrarily long support window happens to be. This basically locks us into the API as that price is too high to ask someone to pay for mere administrative cleanup. All of this indicates to me that it is generally best not refactor and merge things into a much more stable upstream library in a single step. Mistakes in that step then become *much* more costly. -Edward On Fri, Jun 8, 2018 at 2:59 AM Tony Morris wrote:

* Foldable1 -> Semifoldable * Bind -> Semimonad * Apply -> Semiapplicative

What other changes are required?

On Fri, Jun 8, 2018 at 5:20 AM, Edward Kmett wrote:

...

I’m generally on board with doing this proposal, but on a pretty slow time table. Why? There is an active change I want to make to the API of semigroupoids that will require a major version bump and would affect the API for Foldable1 among other classes in the library.

The change is more or less the move to calling it Semifoldable, and refactoring Bind and Apply into Semimonad and Semiapplicative to enable users to find prior literature on the ideas behind them.

This will require a major version bump on the semigroupoids package and I’d like to see the dust settle on that before we proceed with anything that as it involves over 100 downstream dependencies having to move. Fortunately I wrote about half of them. Unfortunately, I’m doing a lot of travel for the next couple of months so it may be a bit of a community effort to get everything patched over once we decide to pull the trigger.

I prefer to make big API changes far outside of base. They are much more expensive to make after things merge in.

-Edward

On Jun 7, 2018, at 9:12 PM, Daniel Cartwright wrote:

For those of you unfamiliar with 'Foldable1', it is a typeclass for nonempty foldable structures, that centres around Semigroup instead of Monoid. I have made a differential on Phabricator for the change here: https://phabricator.haskell.org/D4812

Some discussion at the following links also:

https://ghc.haskell.org/trac/ghc/ticket/13573

https://www.reddit.com/r/haskell/comments/8p531d/ann_safefoldable_safe_wrapp...

https://github.com/ekmett/semigroupoids/issues/49

Note: foldl1 and foldr1 are currently typeclass methods of 'Foldable' and not 'Foldable1', and even though I think they should be, they probably (and shouldn't) be removed in this change, though I hope that eventually they can be moved to Foldable1.

Foldable1 is also unfortunately named due to the suffix '1' being connotated with the conventions surrounded Data.Functor.Classes (Show1, Eq1, etc.). If this naming is seen as sufficiently unfortunate/confusing because of that, then perhaps the name should be changed to something like 'SemiFoldable'. The name change would most likely have to be made in 'semigroupoids' first if that is the case.

_______________________________________________ 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