for Boolean, monoid could form an AND or an OR right?

do we have a preference which one we use?

https://stackoverflow.com/questions/26581100/monoid-bool-in-haskell suggests that Haskell solves this the same way they solve the monoid problem for numbers, by using newtypes to support both

oh, coherence

do both for now IMHO

same as Numbers can do + or *

we don’t have coherence (single instance per type) yet so you can do both

BooleanApi.monoidAnd() && BooleanApi.monoidOr() for example, and BooleanApi.monoid() to default to All

perfect, thanks 🙂

quick review for @jacob talk https://github.com/arrow-kt/arrow/pull/935

please

Let's merge 924 first and then the second one

For commit author to be correct

Nevermind, 935 was approved

Hi, I think we should start removing deprecated classes like

Disjunction

and methods like

Either.get()

. They are deprecated for few months now, I think they can be finally removed. My proposition is to edit message that these methods will be finally removed in 0.8, (or 0.9 - I don't know how many users are still using them).

agreed, I’d go for 0.8. All the deprecated stuff has better alternatives AFAIK

I have question about optics. Why Lens method

set

has (S, B) -> T declaration, but

invoke

required (B) -> (S) -> T. Why are S and B swapped?

That is legacy and may be changed in https://github.com/arrow-kt/arrow/issues/940. In the original implementation all functions were curried in the shape of

(B) -> (S) -> T

but because Arrow doesn’t favor curried functions I choose to align with the rest of Arrow on this.

As I replied in https://github.com/arrow-kt/arrow/pull/920

There is more of this low hanging fruit that will simplify API and usage of Optics.

And we should tackle all at once (or at least in 1 version change)

I don’t think we should actually go through a deprecation phase as we’ve not done that before with breaking changes yet.

Only did this for

yields

deprecation IIRC.

Deprecating this breaking change will be quite tedious due to type erasure so we might as well skip it all together. @raulraja @pakoito

We've only deprecated funktionale API for the sake of the migration

Arrow APIs can just go IMO too

Come to think of it because of AP nobody is writing their own optics anyway. And even if I doubt there will be a lot of them.

BTW we could finally remove these ugly anonymous classes and just put these functions in constructor.

Functions in constructor looks very weird and now all optics would be classes and not interfaces