Proposal: Add Foldable1 from 'semigroupoids' to base

[Edward Kmett]

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 <tmorris at tmorris.net> wrote:

> * Foldable1 -> Semifoldable
> * Bind -> Semimonad
> * Apply -> Semiapplicative
>
> What other changes are required?
>
> On Fri, Jun 8, 2018 at 5:20 AM, Edward Kmett <ekmett at gmail.com> 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 <chessai1996 at gmail.com>
>> 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_wrappers_for_nullpartial/
>>
>> 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 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/20180608/4de76e6e/attachment.html>