Arrow: Apply and Divide typeclasses

[pakoito]

https://leanpub.com/fpmortals/read#leanpub-auto-everything-but-pure

https://leanpub.com/fpmortals/read#leanpub-auto-divide-and-conquer

[pakoito]

Let's skip apply for now, and focus on divide and divisible: https://leanpub.com/fpmortals/read#leanpub-auto-divide-and-conquer

[1Jajen1]

The divide/divisible/decidable part of this is done in #1311

[pedrovgs]

@pakoito @raulraja I could take care of the missing part of this issue tomorrow. I think the missing typeclass is Apply, am I wrong? If so, could you please elaborate what's the expected result of this task? I was thinking in something like:

• Implement the missing Apply typeclass.
• Refactor Applicative typeclass to extend from Apply.
• Create the Apply laws.
• Create the documentation associated with this new typeclass.

The implementation should be backward compatible if I'm not wrong

[pakoito]

Yeah, that's pretty much it. Double check whether Selective extends from Applicative, or the other way around. That's not on the book because the paper came out this year lol

[pedrovgs]

Ok, let's see if I can send a PR today with the implementation 😃

[truizlop]

In case it helps, this is the implementation of Selective that we included in Bow: https://github.com/bow-swift/bow/pull/183

[pedrovgs]

Thanks @truizlop 😃

[JorgeCastilloPrz]

I think we'd also need to double check the data types that were supporting Applicative until now (aka: provided an instance for Applicative) 🤔. I'd say Apply was split from Applicative in Cats for a given reason, probably because they make sense as separate contracts since there could be data types that satisfy the constraints of Apply but not the ones from Applicative. @raulraja should be able to provide more clues about which types to review. I'm afraid this could bring some side refactors in. We'd also need to ensure everything still makes sense from the law tests perspective (as in we're still using the proper data types to run them).

[pedrovgs]

I've been reviewing laws and the implementation for a while and the most important code changes will be related to the laws right now. The applicative instances shouldn't change at all for now because Applicative will extend Apply with the same signature. The good part of having Apply is you can decide when to provide an instance or not for this class. My idea is to provide the implementation change in a backward compatible way and then modify the rest of the code if needed.

[raulraja]

I believe all instances of Apply will need to be added since the @extension processor will only export syntax for declared members in the type class interface. This means that a bunch of members currently exported from Applicative will disappear as you move them to apply. For example:

import arrow.effects.extensions.io.applicative.[functionName]

will no longer be available in that location but instead in:

import arrow.effects.extensions.io.apply.[functionName]

This won't be a backwards compatible change for the most part but that is fine.

[1Jajen1]

Also there are a bunch of methods in Applicative that only need Apply, like tupled and product ...
They should probably be moved as well.