Add AlternativeFlatten #1337
Add AlternativeFlatten #1337
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1337 +/- ##
==========================================
+ Coverage 91.39% 91.47% +0.08%
==========================================
Files 237 241 +4
Lines 3567 3615 +48
Branches 64 120 +56
==========================================
+ Hits 3260 3307 +47
- Misses 307 308 +1
Continue to review full report at Codecov.
|
|
I don't think this makes sense as a separate type-class. |
|
actually not applicative, but something with a |
|
I'm a bit confused. Can you show a proof that this is equivalent to As I said, scalding and spark (not to mention the scala standard library's In the absence of a proof of equivalence, I'd say it is clearly general.
|
|
I could be wrong about this, but after taking a quick glance it seems to me that if we implemented an instance of this type class that only ever did anything with the first item in the provided |
|
I think if you have MonoidK and Applicative on F[_] you can make a law like: pure(a).mapFlatten(f) == f(a).foldRight(empty) { (b, end) => On Mon, Aug 29, 2016 at 09:58 Cody Allen notifications@github.com wrote:
|
|
@johnynek sorry for the delay, I have just gotten around to writing down a few thoughts I've had on this: #1365 |
|
@kcsongor So to help motivate the type class, consider This type is a bit like a It definitely has a However it doesn't a have true It could be that there aren't any However I think it's worth considering this type class on its own merits. Once you have a full-blown |
|
@non Thanks for that example, it was very useful! The assumption I made was that the intermediate values need to be of the same type as the container, but that assumption was too restrictive, since it is enough that we can produce some intermediate values of type I understand that this is useful from a practical perspective, when you can write a more efficient way of filtering, and don't want to use some almost incidental filter function that is derived from other classes. |
|
From a learning perspective, someone who is familiar with Scala and Scala's flatMap may find the principled flatMap irritating or too rigid to work with. Providing a mapFlatten or something similar (that's easily accessible) would ease the adoption process. I would find it convenient in my own work as well. |
|
I'll try to rework this, perhaps based on Alternative (all the examples I
|
|
As a side note, such existence of these type classes that branch off the "main" (I don't like that adjective since it implies theres a certain blessed type class hierarchy but I can't think of a better word right now) type class hierarchy can cause issues. For instance, if you have def foo[F[_]: FunctorFlatten: Applicative] = ...If you try to use anything that requires an implicit |
|
@ceedubs what do you think of the new laws? They seem legit to me? |
There was a problem hiding this comment.
Please see #1379 (comment) I would like to make a decision on that before adding more of such type classes like this.
|
@johnynek are we still interested in this? |
|
This should be in cats-mtl now, no? (Considering it extends classes that I think have moved to cats-mtl. Also, this should be a superclass of |
|
@sellout the examples I care most about are not Monads. |
|
@johnynek Right – I’m just wondering where this class fits in the hierarchy – is it between |
|
Closing stale PRs. Feel free to reopen if there is interest to revive the effort. |
|
Note, SelectiveZero seems to be equivalent to this when G=Option: |
AlternativeFlatten gives us
mapFlattenwith a natural functor like law. Here is an example:fa.mapFlatten { a => List(a, a) }.mapFlatten { b => Some(b) } == fa.mapFlatten { a => List(a, a).map(Some(_)) }This is useful to model the kind of
"flatMap"scala collections have, where we are not really dealing withMonadicflatMap. Also this is very useful for distributed systems such as spark and scalding, which offer this kind of abstraction but the core data type is not a monad (RDD and TypedPipe respectively).I was talking about something like this, and @non suggested we use
G[_]: Foldableas the inner type, upon trying to formalize the laws, I moved toG[_]: Traversewhich seems to satisfy all use cases and allows us to state some nice laws.