Opened 5 years ago
Closed 5 years ago
#5349 closed feature request (fixed)
Proposal: Make Q an instance of Applicative
Reported by: | basvandijk | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Template Haskell | Version: | 7.0.3 |
Keywords: | Cc: | ||
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | None/Unknown | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description
The Q type:
newtype Q a = Q { unQ :: forall m. Quasi m => m a}
currently has an instance for Monad and Functor. I always find it surprising when a monad doesn't have an Applicative instance. So I would like to propose adding an instance for Applicative as well.
I also propose to make Applicative a superclass of the Quasi class:
class (Monad m, Applicative m, Functor m) => Quasi m where ...
During the discussion on the libraries list Michael Snoyman, Wren ng Thornton and Edward Kmett replied positively. There were no objections.
Attachments (2)
Change History (6)
Changed 5 years ago by basvandijk
Changed 5 years ago by basvandijk
comment:1 Changed 5 years ago by simonpj
comment:2 Changed 5 years ago by byorgey
Nothing is lost by the change (other than requiring a tiny bit more work on the part of Quasi instances) since all monads are also applicative functors.
However, I note that (Monad m, Applicative m, Functor m) => ... is redundant, since Applicative m requires Functor m. Hence only (Monad m, Applicative m) => ... is needed.
comment:3 Changed 5 years ago by igloo
- Status changed from new to patch
comment:4 Changed 5 years ago by simonpj
- Resolution set to fixed
- Status changed from patch to closed
Right, applied, thank you.
(I did not apply the TypeSynonymInstances patch because I didn't understand what it was about.)
Just to check, what is lost by this change? Presumably, TH would no longer admit a monad that was not Applicative. Is there any characterisation of what such monads are like? Do we care?