From g9ks157k at acme.softbase.org Wed Jun 4 16:32:53 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Jun 4 16:25:34 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <45017F06-7DD5-4AE8-A734-7366D464EC9B@cse.unsw.edu.au> References: <20080422225339.GA27585@haskell.galois.com> <200804242127.31837.g9ks157k@acme.softbase.org> <45017F06-7DD5-4AE8-A734-7366D464EC9B@cse.unsw.edu.au> Message-ID: <200806042232.53493.g9ks157k@acme.softbase.org> Am Montag, 28. April 2008 06:29 schrieben Sie: > Wolfgang Jeltsch: > > Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty: > > > [?] > > > > > > Hence, anything that is *important* to change, we should change now. > > > > Although I can follow your arguments, I thought that the large and > > disruptive changes should be done for Haskell 2. > > Depends what you mean by Haskell 2. If it is an experimental language > that shares some superficial similarities with Haskell, sure we may > have Haskell 2. If you mean a serious successor of Haskell with the > expectation that many/most Haskell users will eventually move to > Haskell 2, then no. Haskell has been gaining a lot of momentum > recently. That's good and bad, but surely makes it hard to change the > trajectory. (This is, of course, just my personal opinion.) > > > If they should really be done now, we should also fix a lot of other > > things. For example, the Num hierarchy, the Functor/Applicative/Monad > > hierarchy, the fact that there exist Alternative and MonadPlus although we > > have Monoid, the fact that we cannot have contexts like (forall a. Monoid > > (m a)) which is the source for the last problem, the fact that we don?t > > have class aliases, ugly names like fmap and mappend, etc. > > As Lennart and Ganesh have argued, the amount of breaking changes that > we we will be able to fit in without causing serious problems is > limited. > > Manuel Hello again (after a long time), the things I proposed above are mostly library changes which could mostly be made non-disruptive if we had class aliases. Would this make them acceptable for you? Best wishes, Wolfgang From ashley at semantic.org Tue Jun 24 21:16:54 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Jun 24 21:08:34 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad Message-ID: 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 From ashley at semantic.org Thu Jun 26 21:25:28 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Jun 26 21:17:06 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: 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 From ndmitchell at gmail.com Fri Jun 27 05:57:00 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jun 27 05:48:23 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <404396ef0806270257l3d6a5d68ye3767aa740fe20bf@mail.gmail.com> 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 From niklas.broberg at gmail.com Fri Jun 27 08:35:54 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Jun 27 08:27:16 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <404396ef0806270257l3d6a5d68ye3767aa740fe20bf@mail.gmail.com> References: <404396ef0806270257l3d6a5d68ye3767aa740fe20bf@mail.gmail.com> Message-ID: > 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. :-) Cheers, /Niklas From ganesh.sittampalam at credit-suisse.com Fri Jun 27 08:42:46 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Jun 27 08:37:30 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: <404396ef0806270257l3d6a5d68ye3767aa740fe20bf@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B6B3@ELON17P32002A.csfb.cs-group.com> > > 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 ============================================================================== From niklas.broberg at gmail.com Fri Jun 27 08:57:38 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Fri Jun 27 08:49:01 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B6B3@ELON17P32002A.csfb.cs-group.com> References: <404396ef0806270257l3d6a5d68ye3767aa740fe20bf@mail.gmail.com> <78A3C5650E28124399107F21A1FA419401D3B6B3@ELON17P32002A.csfb.cs-group.com> Message-ID: > > 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 From john at repetae.net Fri Jun 27 20:16:56 2008 From: john at repetae.net (John Meacham) Date: Fri Jun 27 20:08:17 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <20080628001656.GJ12977@sliver.repetae.net> 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? From iavor.diatchki at gmail.com Sun Jun 29 21:05:17 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Jun 29 20:56:33 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <20080628001656.GJ12977@sliver.repetae.net> References: <20080628001656.GJ12977@sliver.repetae.net> Message-ID: <5ab17e790806291805p2797dbfbt8690165bb3c90b32@mail.gmail.com> 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 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 > From ashley at semantic.org Mon Jun 30 02:45:29 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Jun 30 02:36:57 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: <5ab17e790806291805p2797dbfbt8690165bb3c90b32@mail.gmail.com> References: <20080628001656.GJ12977@sliver.repetae.net> <5ab17e790806291805p2797dbfbt8690165bb3c90b32@mail.gmail.com> Message-ID: 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 From isaacdupree at charter.net Mon Jun 30 06:53:53 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Jun 30 06:45:06 2008 Subject: PROPOSAL: Make Applicative a superclass of Monad In-Reply-To: References: Message-ID: <4868BB41.1080202@charter.net> 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