Remove WrappedMonad

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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.


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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

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

On Wed, Apr 25, 2018 at 6:11 PM, Andrew Martin <[hidden email]> wrote:
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.


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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

David Feuer
In reply to this post by Andrew Martin
+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
<[hidden email]> wrote:

> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

David Feuer
In reply to this post by Dan Burton
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.

On Wed, Apr 25, 2018 at 9:50 PM, Dan Burton <[hidden email]> wrote:

> 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
>
> On Wed, Apr 25, 2018 at 6:11 PM, Andrew Martin <[hidden email]>
> wrote:
>>
>> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

Henning Thielemann
In reply to this post by Andrew Martin

On Wed, 25 Apr 2018, Andrew Martin wrote:

> 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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

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
<[hidden email]> wrote:

>
> On Wed, 25 Apr 2018, Andrew Martin wrote:
>
>> 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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

Henning Thielemann

On Thu, 26 Apr 2018, David Feuer wrote:

> 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?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove WrappedMonad

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 <[hidden email]> wrote:

On Thu, 26 Apr 2018, David Feuer wrote:

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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries