From HaskellWiki
Hello Conal,
I have a type
defined in
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.
defines an instance
(Applicative a, Monoid m) => Monoid (WrappedApplicative a m)
.
Actually,
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
if an applicative functor is composed with a monoid. Thereby I could get rid of
.
Interestingly,
is also type application. Maybe the above ideas could also be used to remove
. 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
in
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
, defined in
):
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
. How about
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
over more specific-sounding names like
and
. 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
, we should also use
instead of
. In grapefruit-data, I had a module
which used
. Actually, I don't like the
. 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
, 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
and
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
mistake. Do you have a preference about data constructor name, e.g.,
or
?
I like
or
as a replacement for
. Hm. I don't remember why I chose
instead of
.
Btw, I mean to remove
in favor of the
in Data.Traversable.
-- Conal 17:15, 5 December 2007 (UTC)
No preference concerning
and
from my side at the moment.
-- Wolfgang Jeltsch 23:13, 5 December 2007 (UTC)
