Talk:TypeCompose
Hello Conal,
I have a type WrappedApplicative
defined in Data.Monoid.Bonus
which is part of the grapefruit-data package. I introduced it because I wanted to make use of the fact that for every applicative functor a and every monoid m, a m is again a monoid. Data.Monoid.Bonus
defines an instance (Applicative a, Monoid m) => Monoid (WrappedApplicative a m)
.
Actually, WrappedApplicative
is just application of a * -> *
type to a *
type. So it seems much better to define a "composition" type which "composes" a unary type with a nullary type. Such a "composition" would be an instance of Monoid
if an applicative functor is composed with a monoid. Thereby I could get rid of WrappedApplicative
.
Interestingly, WrappedMonad
is also type application. Maybe the above ideas could also be used to remove WrappedMonad
. Maybe this would lead us to libraries which don't introduce all kinds of wrapper types.
What do you think?
-- Wolfgang Jeltsch 18:23, 4 December 2007 (UTC)
I like it. It's the same as App
in Control.Compose
in TypeCompose, isn't it?
newtype App f a = App { unApp :: f a }
instance (Applicative f, Monoid m) => Monoid (App f m) where
mempty = App (pure mempty )
App a `mappend` App b = App (liftA2 mappend a b)
I see this last definition can be improved. I just changed it to the following prettier form (using inApp2
, defined in Compose
):
instance (Applicative f, Monoid m) => Monoid (App f m) where
mempty = App (pure mempty )
mappend = inApp2 (liftA2 mappend)
Maybe a nice infixable name instead of App
. How about
data f :$ a = f :$ a
I guess I'd like two infix ops -- one left-associative and one right-associative.
By the way, have you played with (:*:)
? It's been terrifically useful for me. Also the binary counterpart, (:*:)
, e.g., with arrows (and deep arrows). With these tools, Eros can carry around and compose various kinds of info (values, UIs, types, code, pretty-printings, ...), without impacting the code base. Very powerful.
And yes, I strongly agree with generic names like App
over more specific-sounding names likeWrappedMonad
and WrappedApplicative
. I hadn't thought to recommend that kind of change for standard libraries.
-- Conal 20:18, 4 December 2007 (UTC)