Personal tools

Talk:TypeCompose

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(addition of answer)
(Reply to Wolfgang -- :$, :.)
Line 42: Line 42:
----
----
-
Sorry, I hadn’t looked that deeply into TypeCompose to discover App. Yes, this is what I meant.
+
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.
+
<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. :-(
+
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&nbsp;0.2 instead.
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. ;-)
+
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)
-- [[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)

Revision as of 17:15, 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. :-(
Understood. I think you'll like it. Conal 17:15, 5 December 2007 (UTC)
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)

Thanks for catching my
f :$ a
mistake. Do you have a preference about data constructor name, e.g.,
App
or
Apply
? I like
(:.)
or
(:.:)
as a replacement for
O
. Hm. I don't remember why I chose
(:*:)
instead of
(:*)
. Btw, I mean to remove
Id
in favor of the
Id
in Data.Traversable.

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

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