# Request for comment: functor-monad package

**URL:** <https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387>\
**Category:** Show and Tell\
**Created:** [December 24, 2023, 8:22am UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387 "2023-12-24T08:22:52Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![viercc](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/viercc/32/2988_2.png) [@viercc](https://discourse.haskell.org/u/viercc)\
**Post date:** [December 24, 2023, 8:22am UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387/1 "2023-12-24T08:22:52Z")

</div>

Good end-of-the-year everyone!

I’d like to introduce a category-theory-inspired library I’m making, and I want some feedbacks on it.

- [Haddock](https://viercc.github.io/haddocks/functor-monad/index.html)
  - The linked Haddock is _not_ on Hackage. It’s locally built and manually uploaded by myself. It might go outdated in the future. (I know I should set up CI though…)

- [Repository (GitHub)](https://github.com/viercc/functor-monad/blob/main/functor-monad)

I’m particularly interested in how you think about these points I’m uncertain about.

- Usefulness. I’m yet to find a substantial use of the type classes in my library, `FFunctor` or `FMonad`, in a practical programming task. Should I put it on Hackage despite not knowing the actual value to other users?
- Documentation. The current documentation should have many errors and unfriendly explanations. In addition to my English ability, the math-y nature of this library make it hard for me to write good documentation. Any feedback on documentation is double welcome.

But any kind of comments are welcome!

> <https://github.com/viercc/functor-monad/blob/main/functor-monad/README.md>

---

<div class="post-metadata">

**Author:** ![emilypi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/emilypi/32/5307_2.png) [@emilypi](https://discourse.haskell.org/u/emilypi)\
**Post date:** [December 24, 2023, 8:42am UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387/2 "2023-12-24T08:42:35Z")

</div>

> Usefulness. I’m yet to find a substantial use of the type classes in my library, `FFunctor` or `FMonad`, in a practical programming task. Should I put it on Hackage despite not knowing the actual value to other users?

One package that wasn’t mentioned in the README was [hkd: "higher-kinded data"](https://hackage.haskell.org/package/hkd), which provides everything you do sans `FMonad` and a bit more for various SOP manipulations. I can’t speak to whether `FMonad` would be useful, but I haven’t seen many useful things in the wild that fit that abstraction. I’m interested to see if people have instances lying around that are actually nice to work with. I am a bit invested in this because I abandoned a particular sandbox a while ago ([GitHub - emilypi/higher-functors: Higher-order Functors](https://github.com/emilypi/higher-functors) - feel free to crib anything and everything you care about) that was an attempt to see whether the higher order hierarchy was a useful concept in general, and I had to pull back on account of most “useful” things I worked with needing to be `(k -> Type) -> Type` as opposed to the full `(k -> Type) -> k -> Type`.

I’m stoked that we came up with the saem type signatures and laws for basically everything tho 😄

> Documentation. The current documentation should have many errors and unfriendly explanations. In addition to my English ability, the math-y nature of this library make it hard for me to write good documentation. Any feedback on documentation is double welcome.

Currently, pretty good.

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [December 24, 2023, 1:30pm UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387/3 "2023-12-24T13:30:51Z")

</div>

I believe you could generalize the kind of FFunctor and FMonad to:

```haskell
((k -> Type) -> (k -> Type)) -> Constraint

```

But I think `FStrong` can’t be generalized in this way.

I do have a use case for `k ~ Type -> Type`; I’m hoping to write an ICFP’24 paper about it.

---

<div class="post-metadata">

**Author:** ![viercc](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/viercc/32/2988_2.png) [@viercc](https://discourse.haskell.org/u/viercc)\
**Post date:** [December 25, 2023, 2:08am UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387/4 "2023-12-25T02:08:39Z")

</div>

> you could generalize

I could do, but once I thought that this less-general definition is fine because it has its merit. But thinking again may worth.

Citing README:

> ## Comparison against similar type classes
> 
> (…)
> 
> - From [index-core](https://hackage.haskell.org/package/index-core): `IFunctor`, `IMonad`

Saying the same thing quickly, Any `FFunctor ff` can be encoded as `IFunctor (ff ∘ Coyoneda)`. Many instances can have a more direct `IFunctor ff` instance, but some (like `Free`) can’t avoid the `Coyoneda` indirection.

My another justification of being less general is that a library focusing on a specific structure in detail is no worse than a library for generic things. Anyway, I think the “correct” direction for the ultimate generalization is to have the functor class between arbitrary categories (or higher-categories or …)

One of that specific detail is, like you said, `FStrong ff`. It makes sense only for a `FFunctor ff`. Not just because of its kind, but also for the fact `Day f g` makes sense only for `Functor f` and `Functor g`. A hypothetical “take-`Functor`-and-return-`Contravariant`-functor” with kind `(Type -> Type) -> Type -> Type` can well be `IFunctor` but it wants another class using other tensor products, not `FStrong`.

Or I’m just getting too fixated on the first idea I got.

---

<div class="post-metadata">

**Author:** ![viercc](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/viercc/32/2988_2.png) [@viercc](https://discourse.haskell.org/u/viercc)\
**Post date:** [December 25, 2023, 2:23am UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387/5 "2023-12-25T02:23:17Z")

</div>

Thank you, I’ll add the reference to hkd (and other libraries for `(k -> Type) -> Type`). I’ll read your code too!

> Currently, pretty good.

I’m relieved

---

<div class="post-metadata">

**Author:** ![turion](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/turion/32/989_2.png) [@turion](https://discourse.haskell.org/u/turion)\
**Post date:** [December 29, 2023, 9:15am UTC](https://discourse.haskell.org/t/request-for-comment-functor-monad-package/8387/6 "2023-12-29T09:15:48Z")

</div>

This looks interesting, but I don’t see the decisive advantage over `mmorph` yet. Maybe look for common usage patterns of `mmorph` and try to translate them to situations where your functor is not a monad. Although you’d have to prove then that `mmorph` is not applicable in these situations.

> [@viercc](#):
>
> Should I put it on Hackage despite not knowing the actual value to other users?

Yes, why not? It increases discoverability, and might eventually lead someone with a use case to your library.

> [@viercc](#):
>
> The current documentation should have many errors and unfriendly explanations.

I find your documentation great for a new package, and wish that other libraries also had this quality of documentation. For example, the tables comparing `Functor` vs. `FFunctor` and similar are great.