Re: PROPOSAL: Make Applicative a superclass of Monad
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Make Applicative a superclass of Monad
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 [EMAIL PROTECTED] wrote: 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Make Applicative a superclass of Monad
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-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: PROPOSAL: Make Applicative a superclass of Monad
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 == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: Make Applicative a superclass of Monad
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
Re: PROPOSAL: Make Applicative a superclass of Monad
I wrote: Proposal: Make Applicative (in Control.Applicative) a superclass of Monad (in Control.Monad). So does the silence = approval rule apply here? -- Ashley Yakeley ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
