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)

---

Sorry, I hadn’t looked that deeply into TypeCompose to discover App. Yes, this is what I meant.

(:$) might be nice as its type constructor name (but not as its data constructor name since the data constructor is unary). But if we use (:$) instead of App, we should also use (:.) instead of O. In grapefruit-data, I had a module Data.Composition which used (:.:). Actually, I don’t like the O. While it looks similar to the function composition operator, it isn’t the function composition operator. Instead, it is just a letter, and identifiers made of letters should be descriptive, in my opinion, like App, for example.

I haven’t played with (:*:) and its counterpart yet. No time. :-(

Grapefruit now dropped the modules Data.Monoid.Bonus and Data.Composition and uses TypeCompose 0.2 instead.

By the way, I don’t like that in this wiki one isn’t able to indent answers to previous comments if the answer contains multiple lines of Haskell code. Normally, one should (and should be able to) indent answers by preceding one’s paragraphs with single colons. This doesn’t really work with haskell tags. It’s not composable. ;-)

-- Wolfgang Jeltsch 16:57, 5 December 2007 (UTC)