Personal tools

Talk:TypeCompose

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(Reply to Wolfgang -- App)
(addition of answer)
Line 39: Line 39:
-- [[User:Conal|Conal]] 20:18, 4 December 2007 (UTC)
-- [[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. :-(
 +
 +
Grapefruit now dropped the modules <hask>Data.Monoid.Bonus</hask> and <hask>Data.Composition</hask> and uses TypeCompose&nbsp;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)

Revision as of 16:57, 5 December 2007

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 like
WrappedMonad
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)

Retrieved from "http://www.haskell.org/haskellwiki/Talk:TypeCompose"