Related typeclasses to consider from other packages

[mgsloan]

I almost replied with these thoughts in your libraries email, but I realized that it'd be a distraction from the main topic.

I think Witherable is better expressed by the FunctorMaybe class in reflex:

class FunctorMaybe f where
  -- | Combined mapping and filtering function.
  fmapMaybe :: (a -> Maybe b) -> f a -> f b

Oddly enough, I haven't seen a class like this in many other places. This definition is better, because it doesn't force a Traversable constraint. In the case of reflex, we want to be able to filter event streams. Event streams are not Traversable.

I also think this name is less whimsical than. To me, using the name Witherable in my code is enough reason to not use the library.. And I'd really like to see this gap get filled in a library or base!

I can understand why you would want a Traversable constraint - this allows you to give laws. However, fmapMaybe is quite useful beyond Traversable. IMO, it's perfectly valid for typeclasses to come with laws that mention classes that aren't among their superclasses.

With structures that can have items removed, we can also consider generalizing things like zip. The these package has a few interesting classes for this. Unfortunately, it is not perfect. It demands a nil value when it really shouldn't, as this reduces the number of types that can have instances. For example, consider NonEmpty lists... This is another case of adding too much to a class in order to have more laws (when these laws could instead me expressed as, say, a relationship with the Monoid class, or something like that)

[fumieval]

Oh, fmapMaybe may have laws. For example:

fmapMaybe Just === id
fmapMaybe f . fmapMaybe g === fmapMaybe (f <=< g)

I think FunctorMaybe is just a weaker form of Witherable. Things like event streams are not Witherable so something like FunctorMaybe as a superclass of Witherable may be useful.

I do like to have wither and filterA to filter elements involving effects; FunctorMaybe is not enough for this purpose.

[mgsloan]

True, Witherable does have more capabilities than FmapMaybe, but your mapMaybe should be equivalent to fmapMaybe.

[fumieval]

Yes we would expect fmapMaybe to be the same as mapMaybe.

[andrewthad]

Based on the discussions that have happened on the reflex-frp github (https://github.com/reflex-frp/reflex/issues/19 and https://github.com/reflex-frp/reflex/pull/44), I think that the Traversable constraint could be dropped without any loss of functionality.

[fumieval]

wither implies Traversable and its default definition uses traverse. Dropping Traversable sounds like losing most of the functionality...

Why don't you use filtrable?

[RyanGlScott]

Was this fixed in #13 with the addition of the Filterable class?

[fumieval]

For sure.