Monadic Endo#110
Conversation
|
Yeah, I don't love KEndo. Why the K? Why not MEndo (which I still don't love)? |
For the resemblance to I've consulted the more creative; Any particularly strong feelings towards { |
|
(Those more creative people have suggested matching |
| -- | The intersection of 'Data.Monoid.Endo' and 'Control.Arrow.Kleisli'. This | ||
| -- type provides a 'Monoid' instance for composition of monadic actions | ||
| -- @a -> m a@. | ||
| newtype KEndo m a = KEndo { appKEndo :: a -> m a } |
There was a problem hiding this comment.
This can be generalized to
newtype Endomorphism k a = Endomorphism (k a a)
instance Category k => Semigroup (Endomorphism k a) where
(<>) = coerce (Control.Category..)
instance Category k => Monoid (Endomorphism k a) where
mempty = coerce Control.Category.idThen Endomorphism k a would cover both usual Endo (when k ~ (->)) and monadic endo (when k ~ Kleisli).
There was a problem hiding this comment.
This seems like a great idea. That said, once we have gone this far, I wonder if extra is the right place for it? It seems to be more categorical and less compose a few obvious things?
There was a problem hiding this comment.
This exists in monoid-extras: https://hackage-content.haskell.org/package/monoid-extras-0.7.0.1/docs/Data-Monoid-Endomorphism.html
5 participants
Hello! This adds a very simple semigroup/monoid wrapper for functions
a -> m aI find myself using often. Hoping someone has a better name thanKEndo...