# Talk:TypeCompose

### From HaskellWiki

(notes on WrappedApplicative and type composition) |
(addition of answer concerning App/Apply) |
||

(3 intermediate revisions by 2 users not shown) | |||

Line 3: | Line 3: | ||

I have a type <hask>WrappedApplicative</hask> defined in <hask>Data.Monoid.Bonus</hask> which is part of the [[Grapefruit|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. <hask>Data.Monoid.Bonus</hask> defines an instance <hask>(Applicative a, Monoid m) => Monoid (WrappedApplicative a m)</hask>. |
I have a type <hask>WrappedApplicative</hask> defined in <hask>Data.Monoid.Bonus</hask> which is part of the [[Grapefruit|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. <hask>Data.Monoid.Bonus</hask> defines an instance <hask>(Applicative a, Monoid m) => Monoid (WrappedApplicative a m)</hask>. |
||

− | Actually, <hask>WrappedApplicative</hask> is just application of a <hask>* -> *</hask> type to a <hask>*</hask> 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 <hask>Monoid</hask> if an applicative functor is composed with a monoid. Thereby I could get rid of <hask>WrappedApplicative</hask>. |
+ | Actually, <hask>WrappedApplicative</hask> is just application of a <hask>* -> *</hask> type to a <hask>*</hask> 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 <hask>Monoid</hask> if an applicative functor is composed with a monoid. Thereby I could get rid of <hask>WrappedApplicative</hask>. |

− | Interestingly, <hask>WrappedMonad</hask> is also type application. Maybe the above ideas could also be used to remove <hask>WrappedMonad</hask>. Maybe this would lead us to libraries which don’t introduce all kinds of wrapper types. |
+ | Interestingly, <hask>WrappedMonad</hask> is also type application. Maybe the above ideas could also be used to remove <hask>WrappedMonad</hask>. Maybe this would lead us to libraries which don't introduce all kinds of wrapper types. |

What do you think? |
What do you think? |
||

-- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 18:23, 4 December 2007 (UTC) |
-- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 18:23, 4 December 2007 (UTC) |
||

+ | |||

+ | ---- |
||

+ | |||

+ | I like it. It's the same as <hask>App</hask> in <hask>Control.Compose</hask> in TypeCompose, isn't it? |
||

+ | <haskell> |
||

+ | 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) |
||

+ | </haskell> |
||

+ | I see this last definition can be improved. I just changed it to the following prettier form (using <hask>inApp2</hask>, defined in <hask>Compose</hask>): |
||

+ | <haskell> |
||

+ | instance (Applicative f, Monoid m) => Monoid (App f m) where |
||

+ | mempty = App (pure mempty ) |
||

+ | mappend = inApp2 (liftA2 mappend) |
||

+ | </haskell> |
||

+ | |||

+ | Maybe a nice infixable name instead of <hask>App</hask>. How about |
||

+ | <haskell> |
||

+ | data f :$ a = f :$ a |
||

+ | </haskell> |
||

+ | I guess I'd like two infix ops -- one left-associative and one right-associative. |
||

+ | |||

+ | By the way, have you played with <hask>(:*:)</hask>? It's been terrifically useful for me. Also the binary counterpart, <hask>(:*:)</hask>, 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 <hask>App</hask> over more specific-sounding names like<hask>WrappedMonad</hask> and <hask>WrappedApplicative</hask>. I hadn't thought to recommend that kind of change for standard libraries. |
||

+ | |||

+ | -- [[User:Conal|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. |
||

+ | |||

+ | <hask>(:$)</hask> 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 <hask>(:$)</hask> instead of <hask>App</hask>, we should also use <hask>(:.)</hask> instead of <hask>O</hask>. In grapefruit-data, I had a module <hask>Data.Composition</hask> which used <hask>(:.:)</hask>. Actually, I don't like the <hask>O</hask>. 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 <hask>App</hask>, for example. |
||

+ | |||

+ | I haven't played with <hask>(:*:)</hask> and its counterpart yet. No time. :-( |
||

+ | |||

+ | : Understood. I think you'll like it. [[User:Conal|Conal]] 17:15, 5 December 2007 (UTC) |
||

+ | |||

+ | Grapefruit now dropped the modules <hask>Data.Monoid.Bonus</hask> and <hask>Data.Composition</hask> 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. ;-) |
||

+ | |||

+ | -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 16:57, 5 December 2007 (UTC) |
||

+ | |||

+ | ---- |
||

+ | |||

+ | Thanks for catching my <hask>f :$ a</hask> mistake. Do you have a preference about data constructor name, e.g., <hask>App</hask> or <hask>Apply</hask>? |
||

+ | |||

+ | I like <hask>(:.)</hask> or <hask>(:.:)</hask> as a replacement for <hask>O</hask>. Hm. I don't remember why I chose <hask>(:*:)</hask> instead of <hask>(:*)</hask>. |
||

+ | |||

+ | Btw, I mean to remove <hask>Id</hask> in favor of the <hask>Id</hask> in Data.Traversable. |
||

+ | |||

+ | -- [[User:Conal|Conal]] 17:15, 5 December 2007 (UTC) |
||

+ | |||

+ | ---- |
||

+ | |||

+ | No preference concerning <hask>App</hask> and <hask>Apply</hask> from my side at the moment. |
||

+ | |||

+ | -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 23:13, 5 December 2007 (UTC) |

## Latest revision as of 23:13, 5 December 2007

Hello Conal,

I have a typeWhat do you think?

-- Wolfgang Jeltsch 18:23, 4 December 2007 (UTC)

I like it. It's the same as

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)

instance (Applicative f, Monoid m) => Monoid (App f m) where mempty = App (pure mempty ) mappend = inApp2 (liftA2 mappend)

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-- 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.

- Understood. I think you'll like it. Conal 17:15, 5 December 2007 (UTC)

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)

Thanks for catching my

-- Conal 17:15, 5 December 2007 (UTC)

No preference concerning

-- Wolfgang Jeltsch 23:13, 5 December 2007 (UTC)