PROPOSAL: Make Applicative a superclass of Monad
I had proposed this to the GHC Trac, but it was pointed out that it would break Haskell 98. That proposal has been closed. Proposal: Make Applicative (in Control.Applicative) a superclass of Monad (in Control.Monad). Rename members of Applicative and other functions, to avoid unnecessary duplication. Generalise types of certain existing functions, as appropriate. For example: class Functor f => Applicative f where return :: a -> f a ap :: f (a -> b) -> f a -> f b (>>) :: f a -> f b -> f b (>>) = liftA2 (const id) liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c liftA2 f a b = ap (fmap f a) b -- etc. class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a fail s = error s -- Ashley Yakeley
Hi
So does the "silence = approval" rule apply here?
2 days is not enough time :-) I disagree, its a breaking change from Haskell 98. It also means that if you want to provide syntactic sugar for do notation, i.e. my Test monad, you have to jump through more hoops. http://neilmitchell.blogspot.com/2007/06/test-monad.html Haskell' is about fixing existing practice, if it did go in, you would need some mechanism (i.e. class aliases) to ensure that it didn't break code. Thanks Neil
Haskell' is about fixing existing practice, if it did go in, you would need some mechanism (i.e. class aliases) to ensure that it didn't break code.
... which is why we need class aliases!!
I want to see this change, *and* I want to see class aliases. :-)
I want class aliases, and I want to see this change but *only if* we get class aliases. Functor =/=> Monad is annoying enough, we shouldn't make it worse without fixing the underlying limitation first. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================
I want to see this change, *and* I want to see class aliases. :-)
I want class aliases, and I want to see this change but *only if* we get class aliases. Functor =/=> Monad is annoying enough, we shouldn't make it worse without fixing the underlying limitation first.
Yes, agreed, I should have made my point more clear. That's how I feel too. /Niklas
On Thu, Jun 26, 2008 at 06:25:28PM -0700, Ashley Yakeley wrote:
I wrote:
Proposal: Make Applicative (in Control.Applicative) a superclass of Monad (in Control.Monad).
So does the "silence = approval" rule apply here?
I think that people believe this is generally a good idea, but until the actual language that is haskell' is formalized, library issues are on the backburner. But yeah, I think cleaning up various things about the haskell 98 class hierarchy is a good idea. Even if class aliases are not in the standard itself but this change was, implementing class aliasse would allow individual compilers to provide full back and forwards compatability with haskell 98 and haskell'. So, that might be a route to having our cake and eating it too. We can have the benefit of class aliases without having to break the haskell' rules and standardize such an immature extension since they were designed to be 'transparent' to code that doesn't know about them. Haskell 98 code, and conformant haskell' prime code (as in, code that doesn't explicitly mention class aliases) will coexist peacefully and we will get a lot of experience using class aliases for when they eventually perhaps do get standardized. John -- John Meacham - ⑆repetae.net⑆john⑈
Hello,
I think that this is a good change to make, and I don't think that it
is in any way related to the introduction of class aliases, which is a
fairly major extension (i.e., it requires changes to the compiler),
that we have no experience with, and whose design has not really be
tried out in practise.
As for breaking Haskell'98 code, Haskell' already makes changes that
break existing code (e.g., the new notation for qualified infix
operators). Cabal's ability to track versioned dependencies between
packages should come in handy in implementing this change.
By the way, I once wrote a module that did exactly what Ashley is
proposing and re-exported everything else from the Prelude, so that
you could use it with GHC's "no-implicit-Prelude" option to try out
the design. I could dig it out and post it, if anyone is interested.
-Iavor
On Fri, Jun 27, 2008 at 5:16 PM, John Meacham
On Thu, Jun 26, 2008 at 06:25:28PM -0700, Ashley Yakeley wrote:
I wrote:
Proposal: Make Applicative (in Control.Applicative) a superclass of Monad (in Control.Monad).
So does the "silence = approval" rule apply here?
I think that people believe this is generally a good idea, but until the actual language that is haskell' is formalized, library issues are on the backburner. But yeah, I think cleaning up various things about the haskell 98 class hierarchy is a good idea.
Even if class aliases are not in the standard itself but this change was, implementing class aliasse would allow individual compilers to provide full back and forwards compatability with haskell 98 and haskell'.
So, that might be a route to having our cake and eating it too. We can have the benefit of class aliases without having to break the haskell' rules and standardize such an immature extension since they were designed to be 'transparent' to code that doesn't know about them. Haskell 98 code, and conformant haskell' prime code (as in, code that doesn't explicitly mention class aliases) will coexist peacefully and we will get a lot of experience using class aliases for when they eventually perhaps do get standardized.
John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Iavor Diatchki wrote:
I think that this is a good change to make, and I don't think that it is in any way related to the introduction of class aliases, which is a fairly major extension (i.e., it requires changes to the compiler), that we have no experience with, and whose design has not really be tried out in practise.
I agree with this. At worst, without class aliases, it just means programmers need to copy and paste some boilerplate: instance Functor MyMonad where fmap = applicative_fmap instance Applicative MyMonad where ap = monad_ap (>>) = monad_aseq return = ... -- Ashley Yakeley
Ashley Yakeley wrote:
For example:
class Functor f => Applicative f where return :: a -> f a ap :: f (a -> b) -> f a -> f b (>>) :: f a -> f b -> f b (>>) = liftA2 (const id)
for backwards compatibility of everyone who *uses* Applicative, (and arguably it is a less ugly notation,) : (<*>) = ap (and pure = return) I'm not sure, is the word "ap" even as well known as "<*>" right now? I wonder which one we'd prefer to use in Applicative?
class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a fail s = error s
I want to add to this Applicative=>Monad class: join :: m (m a) -> m a join mm = mm >>= id m >>= f = join (fmap f m) What do others think about that? (P.S. And I guess this hierarchy change is quite independent of the difficult task of removing "fail" from Monad, so I won't discuss that here/now) -Isaac
participants (7)
-
Ashley Yakeley -
Iavor Diatchki -
Isaac Dupree -
John Meacham -
Neil Mitchell -
Niklas Broberg -
Sittampalam, Ganesh