Remove WrappedMonad

[Andrew Martin]

Control.Applicative features a type named WrappedMonad that is used to
recover an Applicative instance from a Monad instance. However, since GHC
7.10, it hasn't been possible to write an Monad instance without an
Applicative instance. Consequently, this type is useless (with one caveat
below). I propose removing this type.

Trac Ticket: https://ghc.haskell.org/trac/ghc/ticket/15027
GitHub PR: https://github.com/ghc/ghc/pull/129

On the PR, David Feuer suggests that the type may have some utility
depending on whether the monad-of-no-return proposal is accepted (and also
on whether DerivingVia is accepted, but this one seems more sure). If Monad
keeps return as a typeclass method, then DerivingVia could be used to
produce an Applicative instance from a Monad instance. If anyone knows the
status of this proposal, that could be helpful. This aside, all indication
of approval or disapproval of this proposal are welcome. Also, I'd really
love to know if anyone is even using this type.

[Dan Burton]

I don't quite understand the comment about DerivingVia.

If Monad keeps return as a typeclass method, then DerivingVia could be used

to produce an Applicative instance from a Monad instance.

Why would DerivingVia be needed for this? If you have your hands on a Monad
instance, then you always have access to the corresponding Applicative
instance, since Applicative is a superclass of Monad. I'm not sure how
DerivingVia comes into play here, or how the "monad of no return" proposal
would change anything about this. Can someone spell it out for me?

-- Dan Burton

Control.Applicative features a type named WrappedMonad that is used to
recover an Applicative instance from a Monad instance. However, since GHC
7.10, it hasn't been possible to write an Monad instance without an
Applicative instance. Consequently, this type is useless (with one caveat
below). I propose removing this type.
Trac Ticket: https://ghc.haskell.org/trac/ghc/ticket/15027
GitHub PR: https://github.com/ghc/ghc/pull/129
On the PR, David Feuer suggests that the type may have some utility
depending on whether the monad-of-no-return proposal is accepted (and also
on whether DerivingVia is accepted, but this one seems more sure). If Monad
keeps return as a typeclass method, then DerivingVia could be used to
produce an Applicative instance from a Monad instance. If anyone knows the
status of this proposal, that could be helpful. This aside, all indication
of approval or disapproval of this proposal are welcome. Also, I'd really
love to know if anyone is even using this type.
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[David Feuer]

Yes. If DerivingVia is accepted, but Monad of no return is rejected,
then some people may choose to write (modulo unresolved syntax)

data M a = ... deriving (Functor via (WrappedMonad m), Applicative via
(WrappedMonad m))
instance Monad M where
return = ...
(>>=) = ...
(>>) = ...

rather than the standard

instance Functor M where
fmap = liftM
instance Applicative M where
pure = return
(<*>) = ap
liftA2 = liftM2

If, however, the Monad-of-no-return proposal goes through, there won't
be any way (using standard classes) to write a Monad instance without
hand-writing an Applicative instance.

So my earlier +1 is very much conditional on that combination *not* happening.

Post by Dan Burton
I don't quite understand the comment about DerivingVia.

Post by Dan Burton
If Monad keeps return as a typeclass method, then DerivingVia could be
used to produce an Applicative instance from a Monad instance.

Why would DerivingVia be needed for this? If you have your hands on a Monad
instance, then you always have access to the corresponding Applicative
instance, since Applicative is a superclass of Monad. I'm not sure how
DerivingVia comes into play here, or how the "monad of no return" proposal
would change anything about this. Can someone spell it out for me?
-- Dan Burton

Post by Dan Burton
Control.Applicative features a type named WrappedMonad that is used to
recover an Applicative instance from a Monad instance. However, since GHC
7.10, it hasn't been possible to write an Monad instance without an
Applicative instance. Consequently, this type is useless (with one caveat
below). I propose removing this type.
Trac Ticket: https://ghc.haskell.org/trac/ghc/ticket/15027
GitHub PR: https://github.com/ghc/ghc/pull/129
On the PR, David Feuer suggests that the type may have some utility
depending on whether the monad-of-no-return proposal is accepted (and also
on whether DerivingVia is accepted, but this one seems more sure). If Monad
keeps return as a typeclass method, then DerivingVia could be used to
produce an Applicative instance from a Monad instance. If anyone knows the
status of this proposal, that could be helpful. This aside, all indication
of approval or disapproval of this proposal are welcome. Also, I'd really
love to know if anyone is even using this type.
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[David Feuer]

+1

I don't know about *serious* use, but there are at least a few
packages that would need modification if it goes away. The ones I was
able to find in not too many minutes of searching:

It shows up in type signatures in

* lens: Control.Lens.Plated, Control.Lens.Traversal,
Control.Lens.IndexedTraversal, and Control.Lens.Wrapped
* base-orphans: Data.Orphans

It has instances (which would have to be removed) in

* semigroupoids: Data.Functor.Alt, Data.Functor.Apply,
Data.Functor.Bind, Data.Functor.Plus

* pointed: Data.Pointed

Among the GHC boot libraries, it appears to be used only in
containers, which only uses it for old base versions.

On Wed, Apr 25, 2018 at 9:11 PM, Andrew Martin

Post by Andrew Martin
Control.Applicative features a type named WrappedMonad that is used to
recover an Applicative instance from a Monad instance. However, since GHC
7.10, it hasn't been possible to write an Monad instance without an
Applicative instance. Consequently, this type is useless (with one caveat
below). I propose removing this type.
Trac Ticket: https://ghc.haskell.org/trac/ghc/ticket/15027
GitHub PR: https://github.com/ghc/ghc/pull/129
On the PR, David Feuer suggests that the type may have some utility
depending on whether the monad-of-no-return proposal is accepted (and also
on whether DerivingVia is accepted, but this one seems more sure). If Monad
keeps return as a typeclass method, then DerivingVia could be used to
produce an Applicative instance from a Monad instance. If anyone knows the
status of this proposal, that could be helpful. This aside, all indication
of approval or disapproval of this proposal are welcome. Also, I'd really
love to know if anyone is even using this type.
--
-Andrew Thaddeus Martin

[Henning Thielemann]

Post by Andrew Martin
Control.Applicative features a type named WrappedMonad that is used to
recover an Applicative instance from a Monad instance. However, since
GHC 7.10, it hasn't been possible to write an Monad instance without an
Applicative instance.

I use it in two packages. I am still using mainly GHC before 7.10 because
of the insecurity introduced by Foldable on tuples in GHC-7.10.

[David Feuer]

Henning, how hard would it be to add some CPP to make those packages
work without WrappedMonad with base >= 4.8.0?

On Thu, Apr 26, 2018 at 1:14 AM, Henning Thielemann

Post by Andrew Martin
Control.Applicative features a type named WrappedMonad that is used to
recover an Applicative instance from a Monad instance. However, since GHC
7.10, it hasn't been possible to write an Monad instance without an
Applicative instance.

I use it in two packages. I am still using mainly GHC before 7.10 because of
the insecurity introduced by Foldable on tuples in GHC-7.10.

[Henning Thielemann]

Post by David Feuer
Henning, how hard would it be to add some CPP to make those packages
work without WrappedMonad with base >= 4.8.0?

I try to prevent CPP whereever possible. I would certainly add my own
WrapMonad. But then, does WrapMonad in 'base' hurt?

[David Feuer]

No, it doesn't hurt much right now. But if there Monad of no return
proposal goes through, I think it will become pretty much unusable. I
therefore think this proposal should be tied to that one.

Separately, the instances don't seem ideal. In particular, I would have
expected it to define

x <$ WrapMonad m = WrapMonad (m >> return x)
(*>) = (>>)

but instead it lets both those methods take their default definitions. It
also seems to be missing a MonadPlus instance.

On Thu, Apr 26, 2018, 2:28 AM Henning Thielemann <

Post by Henning Thielemann

Post by David Feuer
Henning, how hard would it be to add some CPP to make those packages
work without WrappedMonad with base >= 4.8.0?

I try to prevent CPP whereever possible. I would certainly add my own
WrapMonad. But then, does WrapMonad in 'base' hurt?

[Ryan Scott]

Oops, the was supposed to have the "Remove WrappedMonad" title—for
some reason, my mail client dropped it. My apologies.

Ryan S.