From nhn at Cs.Nott.AC.UK Tue Apr 1 16:12:45 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Tue Apr 1 16:13:54 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <20080331222616.GA29829@haskell.galois.com> References: <20080331222616.GA29829@haskell.galois.com> Message-ID: <47F2973D.6070603@cs.nott.ac.uk> > Mon Mar 31 15:26:03 PDT 2008 Simon Marlow > * proposal: remove string gaps Hm. This has escaped me. I don't find the rationale as documented on the Wikipage http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveStringGaps very convincing at all. I've thus added a few more cons: * string gaps are sometimes really helpful for formatting/pretty printing code neatly; the ++ alternative often necessecitates additional bracketing * the simplification of the lexical syntax is very minor * arguably, the syntax highlighting ought to be fixed as that's what at fault, not the language as such I have to confess I find string gaps rather elegant, and I think any sensible language ought to have them! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ndmitchell at gmail.com Tue Apr 1 16:47:30 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 1 16:43:30 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <47F2973D.6070603@cs.nott.ac.uk> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> Message-ID: <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> Hi Henrik, In reality, string gaps are unusable in practice, because of GHC and -cpp. We had some in Yhc at one point, and then breakage happened, so we removed them. To quote from the page: * string gaps cause problems with CPP, which doesn't like the backslash at the end of the line. (a minor consideration, since CPP is not part of the language, and in any case there is cpphs). CPP might not be part of the language, but it is used extensively in many projects - as such it does matter that you don't get obscure errors in one part of a file by using CPP in an entirely different part. The cpphs argument is perfectly sensible, if the GHC -cpp invoked cpphs, but it doesn't, and doesn't seem to be likely to. If you have two features battling each other, you probably need to remove one of them. CPP isn't going to be removed, which kind of forces the issue... Thanks Neil From nhn at Cs.Nott.AC.UK Tue Apr 1 17:35:00 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Tue Apr 1 17:33:45 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> Message-ID: <47F2AA84.8030802@cs.nott.ac.uk> Hi Neil, > If you have two features battling each other, you probably need to > remove one of them. CPP isn't going to be removed, which kind of > forces the issue... Well, for the record, I've used both CPP and string gaps extensively. And all I've done is to be careful to run CPP only where needed (and avoid string gaps there), which seems rather sensible to me anyway, string gaps or not. If various build-systems make selective CPP-ing hard, then I'd definitely argue that the build systems ought to be fixed (I can't believe that would be terribly hard: I've at least done it successfully using make. Not much fun, admittedly, but entirely feasible. Should be much simpler in the context of a more principled, Haskell-oriented build system.) > If you have two features battling each other, you probably need to > remove one of them. CPP isn't going to be removed, which kind of > forces the issue... Well, first of all, I don't think CPP is a feature of Haskell. I do see your point from a pragmatic perspective, but I would argue that auxiliary tool issues (be it CPP, syntax highlighting, or what have you) should be of secondary concern when it comes to language design. As to CPP and Haskell in general, as a matter of principle, I think it's a bad idea to run a preprocessor intended for one very different language on programs of another. Cpphs makes much more sense. However, an advanced Haskell user who thinks CPP is necessary, should understand the implications and take appropriate precautions. So, I still don't find the rationale for removing string gaps very compelling, I'm afraid! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From simonmarhaskell at gmail.com Tue Apr 1 17:46:23 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 1 17:42:24 2008 Subject: patch applied (haskell-prime-status): add RecordPatternMatching and Disambiguate Record Fields Message-ID: <20080401214623.GA594@haskell.galois.com> Tue Apr 1 14:46:12 PDT 2008 Simon Marlow * add RecordPatternMatching and Disambiguate Record Fields M ./status.hs +4 From simonmar.work at gmail.com Tue Apr 1 18:28:08 2008 From: simonmar.work at gmail.com (Simon Marlow) Date: Tue Apr 1 18:24:08 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <47F2973D.6070603@cs.nott.ac.uk> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> Message-ID: <47F2B6F8.5060809@gmail.com> Henrik Nilsson wrote: > > Mon Mar 31 15:26:03 PDT 2008 Simon Marlow > > * proposal: remove string gaps > > Hm. This has escaped me. Not surprising - it wasn't discussed anywhere else, I just thought I should bring it up as a possibility to consider. > I don't find the rationale as documented on the Wikipage > > http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveStringGaps > > very convincing at all. I've thus added a few more cons: > > * string gaps are sometimes really helpful for > formatting/pretty printing code > neatly; the ++ alternative often necessecitates additional > bracketing I can't say I've ever run into that, but I can see how it might be an issue. > * the simplification of the lexical syntax is very minor > > * arguably, the syntax highlighting ought to be fixed as that's what > at fault, not the language as such The point was that if we can make simplifications that make the life of tool writers easier, then all other things being equal we should do so. I wonder if I should suggest removing all those strange ascii esacpe sequences next... Cheers, Simon From nhn at Cs.Nott.AC.UK Tue Apr 1 18:31:32 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Tue Apr 1 18:28:03 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <47F2B6F8.5060809@gmail.com> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <47F2B6F8.5060809@gmail.com> Message-ID: <47F2B7C4.5000701@cs.nott.ac.uk> > I wonder if I should suggest removing all those strange ascii esacpe > sequences next... Well, in contrast to string gaps, I don't think I've ever used those! /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From john at repetae.net Tue Apr 1 18:38:07 2008 From: john at repetae.net (John Meacham) Date: Tue Apr 1 18:34:06 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <47F2973D.6070603@cs.nott.ac.uk> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> Message-ID: <20080401223807.GA21266@sliver.repetae.net> I concur! i use them in quite a few places. If anything, I would like some more powerful style of quoting, like triple quotes in python. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Apr 1 18:42:09 2008 From: john at repetae.net (John Meacham) Date: Tue Apr 1 18:38:06 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> Message-ID: <20080401224209.GB21266@sliver.repetae.net> On Tue, Apr 01, 2008 at 09:47:30PM +0100, Neil Mitchell wrote: > * string gaps cause problems with CPP, which doesn't like the > backslash at the end of the line. (a minor consideration, since CPP is > not part of the language, and in any case there is cpphs). Between the two, I'd say CPP is the much uglier beast. (I tend to use m4 actually when I must use a preprocessor in general, it meshes with haskell better and is pretty ubiquitous). In any case, the simple solution of not using CPP in the same file as string gaps works quite well. It has never really been an issue before. John -- John Meacham - ?repetae.net?john? From ndmitchell at gmail.com Tue Apr 1 18:57:04 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 1 18:53:05 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <47F2AA84.8030802@cs.nott.ac.uk> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> <47F2AA84.8030802@cs.nott.ac.uk> Message-ID: <404396ef0804011557o1161b788vf6a15f4d25bbacd6@mail.gmail.com> Hi > > If you have two features battling each other, you probably need to > > remove one of them. CPP isn't going to be removed, which kind of > > forces the issue... > > Well, for the record, I've used both CPP and string gaps > extensively. And all I've done is to be careful to run CPP > only where needed (and avoid string gaps there), which seems > rather sensible to me anyway, string gaps or not. Having two "features" which can't be used together in the same file seems ridiculous. It gets much worse if you decide "ghc --make -cpp" is the way you want to build your application, as we used to do for Yhc. I suggest that if string gaps don't get removed, then GHC should fix its -cpp flag. Thanks Neil From chak at cse.unsw.edu.au Tue Apr 1 20:03:25 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Apr 1 19:59:28 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <20080401224209.GB21266@sliver.repetae.net> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> <20080401224209.GB21266@sliver.repetae.net> Message-ID: <8F579C05-8BF2-4C6D-A644-F159370BB1D1@cse.unsw.edu.au> John Meacham: > On Tue, Apr 01, 2008 at 09:47:30PM +0100, Neil Mitchell wrote: >> * string gaps cause problems with CPP, which doesn't like the >> backslash at the end of the line. (a minor consideration, since CPP >> is >> not part of the language, and in any case there is cpphs). > > Between the two, I'd say CPP is the much uglier beast. (I tend to > use m4 > actually when I must use a preprocessor in general, it meshes with > haskell better > and is pretty ubiquitous). In any case, the simple solution of > not using CPP in the same file as string gaps works quite well. It has > never really been an issue before. Repeat after me: CPP is evil! Plus I like strings gaps and have used them a lot. Manuel From nhn at Cs.Nott.AC.UK Wed Apr 2 04:46:19 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Wed Apr 2 04:44:04 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <404396ef0804011557o1161b788vf6a15f4d25bbacd6@mail.gmail.com> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> <47F2AA84.8030802@cs.nott.ac.uk> <404396ef0804011557o1161b788vf6a15f4d25bbacd6@mail.gmail.com> Message-ID: <47F347DB.8090302@cs.nott.ac.uk> Hi Neil, > > Well, for the record, I've used both CPP and string gaps > > extensively. And all I've done is to be careful to run CPP > > only where needed (and avoid string gaps there), which seems > > rather sensible to me anyway, string gaps or not. > > Having two "features" which can't be used together in the same file > seems ridiculous. Again, CPP is not part of Haskell as such, and I hope it won't become part either. So anyone using CPP with Haskel should know what they are doing. True, it so happens that CPP does get use a fair bit with Haskell for various reasons, and there is some dedicated tool support for CPP. So it would be good if the version of CPP used through a Haskell tool chain was Haskell aware. > It gets much worse if you decide "ghc --make -cpp" > is the way you want to build your application, as we used to do for > Yhc. Wouldn't {-# LANGUAGE CPP #-} be a viable option in the, presumably rather few, files where CPP really is used? (That's also rather good documentation for the reader of the file, incidentally.) Again, running an entire project through CPP just because a few files needs CPP-ing, is something I at least would try to avoid. > I suggest that if string gaps don't get removed, then GHC should > fix its -cpp flag. Would be nice, but probably not an H' discussion topic, unless you're arguing that some kind of CPP facility is mandated by the H' standard? Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From simonmarhaskell at gmail.com Thu Apr 3 13:26:46 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 3 13:22:40 2008 Subject: patch applied (haskell-prime-status): add wiki link for CompositionAsDot Message-ID: <20080403172645.GA5825@haskell.galois.com> Thu Apr 3 10:26:35 PDT 2008 Simon Marlow * add wiki link for CompositionAsDot M ./status.hs -1 +1 From simonmarhaskell at gmail.com Thu Apr 3 13:27:27 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 3 13:23:20 2008 Subject: patch applied (haskell-prime-status): fix markup Message-ID: <20080403172727.GA5880@haskell.galois.com> Thu Apr 3 10:27:20 PDT 2008 Simon Marlow * fix markup M ./status.hs -1 +1 From marlowsd at gmail.com Thu Apr 3 14:24:53 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Apr 3 14:20:49 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <404396ef0804011557o1161b788vf6a15f4d25bbacd6@mail.gmail.com> References: <20080331222616.GA29829@haskell.galois.com> <47F2973D.6070603@cs.nott.ac.uk> <404396ef0804011347s6fc3a19an262564193c0be18e@mail.gmail.com> <47F2AA84.8030802@cs.nott.ac.uk> <404396ef0804011557o1161b788vf6a15f4d25bbacd6@mail.gmail.com> Message-ID: <47F520F5.9000900@gmail.com> Neil Mitchell wrote: > Hi > >> > If you have two features battling each other, you probably need to >> > remove one of them. CPP isn't going to be removed, which kind of >> > forces the issue... >> >> Well, for the record, I've used both CPP and string gaps >> extensively. And all I've done is to be careful to run CPP >> only where needed (and avoid string gaps there), which seems >> rather sensible to me anyway, string gaps or not. > > Having two "features" which can't be used together in the same file > seems ridiculous. It gets much worse if you decide "ghc --make -cpp" > is the way you want to build your application, as we used to do for > Yhc. I suggest that if string gaps don't get removed, then GHC should > fix its -cpp flag. GHC is unlikely to "fix" its -cpp flag unfortunately, because the problem is with CPP, not GHC. The best we can do is document the problem, which we have done. Cheers, Simon From simonmarhaskell at gmail.com Thu Apr 3 14:29:33 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 3 14:25:24 2008 Subject: patch applied (haskell-prime-status): reject the removal of string gaps Message-ID: <20080403182933.GA7593@haskell.galois.com> Thu Apr 3 11:29:25 PDT 2008 Simon Marlow * reject the removal of string gaps M ./status.hs -1 +1 From simonmarhaskell at gmail.com Thu Apr 3 14:30:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 3 14:26:29 2008 Subject: patch applied (haskell-prime-status): fix error Message-ID: <20080403183037.GA7686@haskell.galois.com> Thu Apr 3 11:30:27 PDT 2008 Simon Marlow * fix error M ./status.hs -1 +1 From simonmarhaskell at gmail.com Thu Apr 10 16:36:24 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Apr 10 16:31:54 2008 Subject: patch applied (haskell-prime-status): reject parallel list comprehensions Message-ID: <20080410203623.GA22007@haskell.galois.com> Thu Apr 10 13:36:10 PDT 2008 Simon Marlow * reject parallel list comprehensions M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080410203610-8214f-d0faac4d781ec058adbab596037afcbdc1f55e92.gz From g9ks157k at acme.softbase.org Fri Apr 11 10:02:05 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Apr 11 09:57:38 2008 Subject: patch applied (haskell-prime-status): proposal: remove string gaps In-Reply-To: <47F520F5.9000900@gmail.com> References: <20080331222616.GA29829@haskell.galois.com> <404396ef0804011557o1161b788vf6a15f4d25bbacd6@mail.gmail.com> <47F520F5.9000900@gmail.com> Message-ID: <200804111602.05861.g9ks157k@acme.softbase.org> Am Donnerstag, 3. April 2008 20:24 schrieb Simon Marlow: > Neil Mitchell wrote: > [?] > > Having two "features" which can't be used together in the same file > > seems ridiculous. It gets much worse if you decide "ghc --make -cpp" > > is the way you want to build your application, as we used to do for > > Yhc. I suggest that if string gaps don't get removed, then GHC should > > fix its -cpp flag. > > GHC is unlikely to "fix" its -cpp flag unfortunately, because the > problem is with CPP, not GHC. The best we can do is document the > problem, which we have done. Couldn?t you ?fix? the -cpp flag by letting GHC use cpphs instead of C?s cpp? > Cheers, > Simon Best wishes, Wolfgang From g9ks157k at acme.softbase.org Fri Apr 11 10:19:26 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Apr 11 10:15:11 2008 Subject: patch applied (haskell-prime-status): add overloaded string literals In-Reply-To: <20080331223149.GA29967@haskell.galois.com> References: <20080331223149.GA29967@haskell.galois.com> Message-ID: <200804111619.26566.g9ks157k@acme.softbase.org> Am Dienstag, 1. April 2008 00:31 schrieb Simon Marlow: > Mon Mar 31 15:31:44 PDT 2008 Simon Marlow > * add overloaded string literals > > M ./status.hs +2 Hello, although I like overloaded string literals very much, I see one problem with the current implementation of them in GHC. It?s the class name ?IsString?. No other Haskell class name I know starts with ?Is?; we don?t have ?IsNum?, ?IsMonad?, etc. Would it be possible to change the class name ?IsString? to something different? Would it be possible to remove the type alias ?String? and let ?String? be the class name? Can I add this remark somewhere on the wiki? Best wishes, Wolfgang From bulat.ziganshin at gmail.com Fri Apr 11 10:48:28 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Apr 11 10:47:50 2008 Subject: patch applied (haskell-prime-status): add overloaded string literals In-Reply-To: <200804111619.26566.g9ks157k@acme.softbase.org> References: <20080331223149.GA29967@haskell.galois.com> <200804111619.26566.g9ks157k@acme.softbase.org> Message-ID: <12710269812.20080411184828@gmail.com> Hello Wolfgang, Friday, April 11, 2008, 6:19:26 PM, you wrote: > Would it be possible to change the class name ?IsString? to something > different? Would it be possible to remove the type alias ?String? and > let ?String? be the class name? Can I add this remark somewhere on the wiki? this reminds me one idea i've once proposed to discuss: allow to use class names in type signatures with obvious translation to "classic" code: putStr :: String -> IO () means putStr :: (String a) => a -> IO () writing a lot of polymorphic code for Streams lib, i've found this feature very useful - with current standard, type signatures using type classes are very hard to read: -- | Copy `size` bytes from one BlockStream to another copyStream :: (BlockStream h1, BlockStream h2, Integral size) => h1 -> h2 -> size -> IO () -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Mon Apr 14 14:44:40 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 14:39:58 2008 Subject: patch applied (haskell-prime-status): remove duplicate entry for MonomorphicPatternBindings Message-ID: <20080414184440.GA1403@haskell.galois.com> Thu Apr 10 14:57:46 PDT 2008 Simon Marlow * remove duplicate entry for MonomorphicPatternBindings M ./status.hs -2 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080410215746-8214f-4bb9e0bb5211c41ab10a825e163e6e15ff8c1028.gz From simonmarhaskell at gmail.com Mon Apr 14 14:44:42 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 14:40:01 2008 Subject: patch applied (haskell-prime-status): add standalone derived instances Message-ID: <20080414184442.GA1427@haskell.galois.com> Mon Apr 14 11:44:31 PDT 2008 Simon Marlow * add standalone derived instances M ./status.hs +2 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414184431-8214f-3385be0e5555e2c6b9a4490de21a35f644e3041e.gz From simonmarhaskell at gmail.com Mon Apr 14 14:45:50 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 14:41:06 2008 Subject: patch applied (haskell-prime-status): edit standalone derived instances Message-ID: <20080414184549.GA1525@haskell.galois.com> Mon Apr 14 11:45:43 PDT 2008 Simon Marlow * edit standalone derived instances M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414184543-8214f-1b26a4a95da64dee7b20bbc2f595c3168bce8a1b.gz From simonmarhaskell at gmail.com Mon Apr 14 14:49:51 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 14:45:11 2008 Subject: patch applied (haskell-prime-status): add liberalised type synonyms Message-ID: <20080414184950.GA1608@haskell.galois.com> Mon Apr 14 11:49:45 PDT 2008 Simon Marlow * add liberalised type synonyms M ./status.hs +2 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414184945-8214f-9ef7e948faad471a9c4924002056b4fc1d3ca1fb.gz From simonmarhaskell at gmail.com Mon Apr 14 15:04:41 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 14:59:59 2008 Subject: patch applied (haskell-prime-status): accept RelaxedDependencyAnalysis Message-ID: <20080414190441.GA1947@haskell.galois.com> Mon Apr 14 12:01:23 PDT 2008 Simon Marlow * accept RelaxedDependencyAnalysis M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414190123-8214f-7672248c42f0ce6fa6576e68fe09dd94c6704de5.gz From simonmarhaskell at gmail.com Mon Apr 14 15:04:42 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 15:00:00 2008 Subject: patch applied (haskell-prime-status): add John Meacham's layout proposal Message-ID: <20080414190442.GA1970@haskell.galois.com> Mon Apr 14 12:04:30 PDT 2008 Simon Marlow * add John Meacham's layout proposal M ./status.hs +2 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414190430-8214f-810333212d57fcd21f9e15177ea4ebe551c00bd9.gz From simonmarhaskell at gmail.com Mon Apr 14 15:07:39 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 15:02:55 2008 Subject: patch applied (haskell-prime-status): accept scoped type variables Message-ID: <20080414190738.GA2072@haskell.galois.com> Mon Apr 14 12:05:50 PDT 2008 Simon Marlow * accept scoped type variables M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414190550-8214f-d308ff4f7fc7ca2c58b885792e45ab33c2735e77.gz From simonmarhaskell at gmail.com Mon Apr 14 15:07:40 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 14 15:02:58 2008 Subject: patch applied (haskell-prime-status): remove duplicate EmptyDataDeclarations Message-ID: <20080414190740.GA2095@haskell.galois.com> Mon Apr 14 12:07:25 PDT 2008 Simon Marlow * remove duplicate EmptyDataDeclarations M ./status.hs -1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080414190725-8214f-4422f9cc0388b6d8231cdce5821b1365ffe4b302.gz From simonmarhaskell at gmail.com Tue Apr 15 13:51:44 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 13:46:59 2008 Subject: patch applied (haskell-prime-status): add DerivingInstances Message-ID: <20080415175144.GA29032@haskell.galois.com> Tue Apr 15 10:50:54 PDT 2008 Simon Marlow * add DerivingInstances M ./status.hs +2 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415175054-8214f-b951f87924270aa36c2af9110f025a6caebe0d62.gz From simonmarhaskell at gmail.com Tue Apr 15 13:55:39 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 13:50:53 2008 Subject: patch applied (haskell-prime-status): reject caseless Underscore Message-ID: <20080415175539.GA29153@haskell.galois.com> Tue Apr 15 10:55:30 PDT 2008 Simon Marlow * reject caseless Underscore M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415175530-8214f-7a0e97f3952cddee8178c5929ae2869abb22c060.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:36 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:08:51 2008 Subject: patch applied (haskell-prime-status): TypeSynonymInstances: probably accept ==> undecided Message-ID: <20080415181336.GA29581@haskell.galois.com> Tue Apr 15 11:10:10 PDT 2008 Simon Marlow * TypeSynonymInstances: probably accept ==> undecided M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181010-8214f-eb96ed362e394a7ec5ca2d0b2849bc331d7a3b8c.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:38 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:08:53 2008 Subject: patch applied (haskell-prime-status): NondecreasingIndentation: probably accept ==> accept Message-ID: <20080415181338.GA29604@haskell.galois.com> Tue Apr 15 11:10:51 PDT 2008 Simon Marlow * NondecreasingIndentation: probably accept ==> accept M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181051-8214f-b71764fa8771790d94565efcac663d7c17356ade.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:39 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:08:54 2008 Subject: patch applied (haskell-prime-status): QualifiedIdentifiers: probably accept ==> undecided Message-ID: <20080415181339.GA29621@haskell.galois.com> Tue Apr 15 11:11:16 PDT 2008 Simon Marlow * QualifiedIdentifiers: probably accept ==> undecided M ./status.hs -2 +3 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181116-8214f-61de042c56edab3210e49e968d9e88a24961ef1f.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:40 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:08:56 2008 Subject: patch applied (haskell-prime-status): FlexibleInstances: probably accept ==> undecided Message-ID: <20080415181340.GA29639@haskell.galois.com> Tue Apr 15 11:11:30 PDT 2008 Simon Marlow * FlexibleInstances: probably accept ==> undecided M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181130-8214f-d06c6651a99a5cf27a678f1417bf85044114ccfb.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:42 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:08:56 2008 Subject: patch applied (haskell-prime-status): NewPragmas: probably accept ==> undecided Message-ID: <20080415181342.GA29656@haskell.galois.com> Tue Apr 15 11:11:44 PDT 2008 Simon Marlow * NewPragmas: probably accept ==> undecided M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181144-8214f-151ac2e23e15840c84b20d83632672c74c5a8b35.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:44 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:09:01 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided Message-ID: <20080415181344.GA29673@haskell.galois.com> Tue Apr 15 11:12:08 PDT 2008 Simon Marlow * BangPatterns: probably accept ==> undecided M ./status.hs -2 +3 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181208-8214f-5e1ae9e40a9feb2afbd077b0e2f623dc0bdbd02f.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:45 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:09:02 2008 Subject: patch applied (haskell-prime-status): NewtypeDeriving: probably accept ==> undecided Message-ID: <20080415181345.GA29690@haskell.galois.com> Tue Apr 15 11:12:27 PDT 2008 Simon Marlow * NewtypeDeriving: probably accept ==> undecided M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181227-8214f-d75f6774183661274c106aded5c7a4a2d9b96cd8.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:46 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:09:02 2008 Subject: patch applied (haskell-prime-status): improve [wiki:Defaulting] rules: probably accept ==> undecided Message-ID: <20080415181346.GA29707@haskell.galois.com> Tue Apr 15 11:12:42 PDT 2008 Simon Marlow * improve [wiki:Defaulting] rules: probably accept ==> undecided M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181242-8214f-9565b50d490a06fd126df3ec64a5a4984c4fcb6c.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:48 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:09:03 2008 Subject: patch applied (haskell-prime-status): KindAnnotations: probably accept ==> accept Message-ID: <20080415181348.GA29724@haskell.galois.com> Tue Apr 15 11:12:55 PDT 2008 Simon Marlow * KindAnnotations: probably accept ==> accept M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181255-8214f-823a0b473064b7ce419f9c7418f8e9fceafa38cd.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:49 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:09:06 2008 Subject: patch applied (haskell-prime-status): MonomorphicPatternBindings: probably accept ==> undecided Message-ID: <20080415181349.GA29741@haskell.galois.com> Tue Apr 15 11:13:11 PDT 2008 Simon Marlow * MonomorphicPatternBindings: probably accept ==> undecided M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181311-8214f-618ae9b32fb53764506ae5552248468ba24907cf.gz From simonmarhaskell at gmail.com Tue Apr 15 14:13:50 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:09:06 2008 Subject: patch applied (haskell-prime-status): remove the "probably accept" category Message-ID: <20080415181350.GA29758@haskell.galois.com> Tue Apr 15 11:13:22 PDT 2008 Simon Marlow * remove the "probably accept" category M ./status.hs -7 +2 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415181322-8214f-18a5e99492ad50ab55d2ea8ad4921e79c3bb4775.gz From simonmarhaskell at gmail.com Tue Apr 15 14:58:03 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 14:53:19 2008 Subject: patch applied (haskell-prime-status): Classify each issue by the section of the report it applies (most) too Message-ID: <20080415185802.GA30938@haskell.galois.com> Tue Apr 15 11:57:57 PDT 2008 Simon Marlow * Classify each issue by the section of the report it applies (most) too M ./status.hs -87 +185 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415185757-8214f-990e7a652e8193ae41b378242eb762f26221f409.gz From simonmarhaskell at gmail.com Tue Apr 15 16:44:01 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 16:39:16 2008 Subject: patch applied (haskell-prime-status): refactor, and emit issues grouped by section Message-ID: <20080415204401.GA673@haskell.galois.com> Tue Apr 15 13:43:55 PDT 2008 Simon Marlow * refactor, and emit issues grouped by section M ./status.hs -208 +402 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415204355-8214f-0d99ed3258c2d09d5e61f8d895c8cd0a43252bd0.gz From simonmarhaskell at gmail.com Tue Apr 15 16:45:03 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 16:40:18 2008 Subject: patch applied (haskell-prime-status): GHC 6.6 compat Message-ID: <20080415204503.GA769@haskell.galois.com> Tue Apr 15 13:44:57 PDT 2008 Simon Marlow * GHC 6.6 compat M ./status.hs -1 +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415204457-8214f-8d1329365a4d9497985811d3299dea3084a3e950.gz From simonmarhaskell at gmail.com Tue Apr 15 16:46:58 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 16:42:12 2008 Subject: patch applied (haskell-prime-status): cleanup output Message-ID: <20080415204658.GA819@haskell.galois.com> Tue Apr 15 13:46:51 PDT 2008 Simon Marlow * cleanup output M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415204651-8214f-511db01c9e0fdbff2c25e54473527b5d4799ab38.gz From simonmarhaskell at gmail.com Tue Apr 15 16:49:29 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 15 16:44:45 2008 Subject: patch applied (haskell-prime-status): add [[PageOutline]] Message-ID: <20080415204929.GA881@haskell.galois.com> Tue Apr 15 13:49:23 PDT 2008 Simon Marlow * add [[PageOutline]] M ./status.hs +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080415204923-8214f-e53edf350e27d1b6136f117b4e4c52296e4ae934.gz From dons at galois.com Wed Apr 16 11:06:28 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 16 11:01:41 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <20080415181344.GA29673@haskell.galois.com> References: <20080415181344.GA29673@haskell.galois.com> Message-ID: <20080416150628.GD12207@scytale.galois.com> simonmarhaskell: > Tue Apr 15 11:12:08 PDT 2008 Simon Marlow > * BangPatterns: probably accept ==> undecided > > M ./status.hs -2 +3 I think we absolutely must have a story on bang patterns for H'. They're now very widely used in low level code, where we either don't trust, or need to tune, the strictness analyser. And using CPP for this is just not acceptable, and I still cry a little inside when I have to use #define STRICT1(f) f a | a `seq` False = undefined #define STRICT2(f) f a b | a `seq` b `seq` False = undefined #define STRICT3(f) f a b c | a `seq` b `seq` c `seq` False = undefined STRICT2(f) f x y = ... to achieve portability to Hugs/nhc98 of Data.ByteString. In the list of features "required for Haskell in practice", bang patterns are way up there. -- Don From bulat.ziganshin at gmail.com Wed Apr 16 11:19:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 16 11:17:00 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <20080416150628.GD12207@scytale.galois.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> Message-ID: <1857129922.20080416191952@gmail.com> Hello Don, Wednesday, April 16, 2008, 7:06:28 PM, you wrote: > In the list of features "required for Haskell in practice", bang patterns are > way up there. +1. they are also required to achieve good results in various shutouts :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Wed Apr 16 13:22:14 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 16 13:17:24 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <20080416150628.GD12207@scytale.galois.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> Message-ID: <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> Hi > In the list of features "required for Haskell in practice", bang patterns are > way up there. But their syntax has issues: a!b = ... Did I just define the function "a" or the function "!"? I'm not saying they shouldn't be accepted, but the story should be a little clearer about this as well! Thanks Neil From ndmitchell at gmail.com Wed Apr 16 13:24:50 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 16 13:20:01 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> Message-ID: <404396ef0804161024h68ac6d84t6c262558278d5dad@mail.gmail.com> Hi > a!b = ... > > Did I just define the function "a" or the function "!"? > > I'm not saying they shouldn't be accepted, but the story should be a > little clearer about this as well! For what it is worth, in discussions with Matt, we wondered if eliminating infix function definition altogether was an option. We decided that you probably don't gain much by defining functions infix, as you have to define their type prefix anyway. Of course you still want to use functions infix, but that is a separate issue. Of course, this can't be done for Haskell', but might make an interesting alternative design. Thanks Neil From simonmarhaskell at gmail.com Wed Apr 16 13:25:18 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 16 13:20:29 2008 Subject: patch applied (haskell-prime-status): add QualifiedOperators proposal Message-ID: <20080416172518.GA25203@haskell.galois.com> Wed Apr 16 10:25:08 PDT 2008 Simon Marlow * add QualifiedOperators proposal M ./status.hs +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080416172508-8214f-1d31cbfdec2e09db90231720fa5d207f4efa1126.gz From simonmarhaskell at gmail.com Wed Apr 16 13:26:23 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 16 13:21:36 2008 Subject: patch applied (haskell-prime-status): typo Message-ID: <20080416172623.GA25247@haskell.galois.com> Wed Apr 16 10:26:16 PDT 2008 Simon Marlow * typo M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080416172616-8214f-9e6f613425fd3199fbd2ff9acbb67be188734af7.gz From john at repetae.net Thu Apr 17 20:39:06 2008 From: john at repetae.net (John Meacham) Date: Thu Apr 17 20:34:12 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> Message-ID: <20080418003906.GB17560@sliver.repetae.net> On Wed, Apr 16, 2008 at 06:22:14PM +0100, Neil Mitchell wrote: > Hi > > > In the list of features "required for Haskell in practice", bang patterns are > > way up there. > > But their syntax has issues: > > a!b = ... > > Did I just define the function "a" or the function "!"? Interesting note, if we solve this, then we can apply the same thing to the treatment of ~ and regain it as a usable operator. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Fri Apr 18 03:36:42 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 18 03:31:50 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <20080418003906.GB17560@sliver.repetae.net> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> | > > In the list of features "required for Haskell in practice", bang patterns are | > > way up there. | > | > But their syntax has issues: | > | > a!b = ... | > | > Did I just define the function "a" or the function "!"? | | Interesting note, if we solve this, then we can apply the same thing to | the treatment of ~ and regain it as a usable operator. In GHC I implemented a pretty grotesque hack. I really really wanted f !x !y = e to work as you'd expect. But because of the infix operator thing, that parses as (f ! x) ! y = e A gruesome post-processing step restores the parse we want, for the special case of !. It's not nice, but I didn't have the luxury of changing anything else, which we do now. Not allowing infix functions on the LHS would be a notable simplification. Constructors in patterns should still be infix of course: f (a :=: b) = ... In any case, I've always thought this was weird: Just x == Just y = x == y Simon From nhn at Cs.Nott.AC.UK Fri Apr 18 05:41:30 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Fri Apr 18 05:38:16 2008 Subject: Infix type and function definitions In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48086CCA.1020402@cs.nott.ac.uk> Hi, Simon PJ wrote (Re: BangPatterns: probably accept ==> undecided): > Not allowing infix functions on the LHS would be a notable > simplification. And a little later (Re: Infix type constructors): > What we *want* is to say > > data a + b = Left a | Right b > > That is, we want to define the type *constructor* (+) Just to clarify, issues of what names can be used for type constructors aside, are you proposing dropping infix syntax for defining functions, but retaining infix syntax for defining types (and type families etc.)? Or would the last example have to be written data (+) a b = Left a | Right b ? All the best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ganesh.sittampalam at credit-suisse.com Fri Apr 18 05:54:09 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Apr 18 05:49:47 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3315@ELON17P32002A.csfb.cs-group.com> Simon Peyton Jones wrote: > Not allowing infix functions on the LHS would be a notable > simplification. This would significantly weaken a useful property of Haskell, that definitions and uses often share the same concrete syntax. It's very natural to be able to define things that way and it would be a real shame to lose it (and I think it would break a lot of existing code). > In any case, I've always thought this was weird: > Just x == Just y = x == y It takes a little getting used to, but I don't find it that weird. I wouldn't mind if just infix definitions of (!) were banned, though of course that would be an unpleasant non-orthogonality. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From john at repetae.net Fri Apr 18 05:54:51 2008 From: john at repetae.net (John Meacham) Date: Fri Apr 18 05:49:55 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080418095451.GG17560@sliver.repetae.net> On Fri, Apr 18, 2008 at 08:36:42AM +0100, Simon Peyton-Jones wrote: > Not allowing infix functions on the LHS would be a notable > simplification. Constructors in patterns should still be infix of > course: f (a :=: b) = ... I don't know, I think this will confuse things, especially for newbies, people tend to say things like: a + b = foo as "a plus b is foo", and so would probably naturally write it in infix form, it would be a source of confusion if the compiler didn't accept it. I don't think saying ~ and ! are operators unless they 1. immediately followed by a '(', a letter, or an underscore 2. are preceded by whitespace or BOL is that onerous. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Fri Apr 18 10:49:24 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 18 10:44:36 2008 Subject: Infix type and function definitions In-Reply-To: <48086CCA.1020402@cs.nott.ac.uk> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <48086CCA.1020402@cs.nott.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE523A343@EA-EXMSG-C334.europe.corp.microsoft.com> | Just to clarify, issues of what names can be used for | type constructors aside, are you proposing dropping | infix syntax for defining functions, but retaining infix | syntax for defining types (and type families etc.)? | | Or would the last example have to be written | | data (+) a b = Left a | Right b I *am* proposing that varsyms become type *constructors* not type *variables*. I can see arguments both ways for allowing definitions in infix form, and I don't have a strong position either way. Simon From marlowsd at gmail.com Mon Apr 21 14:06:51 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 14:01:48 2008 Subject: DRAFT: Haskell' status update Message-ID: <480CD7BB.2040601@gmail.com> Those on the Haskell' mailing list may have seen recent signs of activity on the Haskell' front. I thought I should clarify the current status, and update the community on our plans for Haskell'. The main sticking point in the design of Haskell' has been the type system: namely whether Haskell' should have Functional Dependencies or Type Families. This issue is still undecided, although the experts are hard at work on developing a stronger understanding of Type Families in particular. Nevertheless, the committee feels that we cannot have a Haskell' without some way to resolve ambiguities when using multi-parameter type classes, be it Functional Dependencies (FDs) or Type Families (TFs). For one thing, a great deal of existing code uses FDs or depends on code that does, so unless we adopt one of these extensions all this code will still exist outside of Haskell', and that is far from ideal. So we decided to proceed in two stages: - "Haskell' alpha" will be a complete language specification, including all the modifications and additions we want to make to the language *except* for FDs or TFs. - Haskell' will follow afterward, adding either FDs or TFs. The motivation for this two-stage approach is that we can make progress on all the other parts of the language without being blocked on the type system, we can start work on implementing Haskell' alpha in our compilers, users can start using the new standard, and we can gain some experience with using it in practice. On the process side of things, we're now tracking the status of all language design proposals on this page: http://hackage.haskell.org/trac/haskell-prime/wiki/Status and as usual all the Haskell' resources are on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki The committee have been discussing various proposals amongst ourselves over the past few weeks, with the goal of making as many concrete decisions as possible. However, the general policy is still for technical discussions to take place in public, as far as possible. Changes to the status page are sent to the public mailing list, and we welcome comments on any of the issues, regardless of status. Thanks for your patience :-) And rest assured that progress is being made! Cheers, Simon (and the Haskell' committee) From marlowsd at gmail.com Mon Apr 21 14:08:55 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 14:03:51 2008 Subject: Haskell' status update In-Reply-To: <480CD7BB.2040601@gmail.com> References: <480CD7BB.2040601@gmail.com> Message-ID: <480CD837.8070601@gmail.com> Simon Marlow wrote: Subject: DRAFT: Haskell' status update of course, that shouldn't have said "DRAFT". Cheers, Simon From marlowsd at gmail.com Mon Apr 21 14:12:58 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 14:07:57 2008 Subject: Proposal: change to qualified operator syntax Message-ID: <480CD92A.4010408@gmail.com> Folks, Please comment on the following proposed change to qualified operator syntax: http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators Cheers, Simon From simonmarhaskell at gmail.com Mon Apr 21 14:30:47 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Apr 21 14:25:44 2008 Subject: patch applied (haskell-prime-status): add wiki link for ArrayIndexing Message-ID: <20080421183047.GA21429@haskell.galois.com> Mon Apr 21 11:30:40 PDT 2008 Simon Marlow * add wiki link for ArrayIndexing M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080421183040-8214f-02ff20c870f45e474bf91dc581b45e3a20e6bea7.gz From marlowsd at gmail.com Mon Apr 21 14:38:51 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 14:33:51 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <20080418095451.GG17560@sliver.repetae.net> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> Message-ID: <480CDF3B.1090604@gmail.com> John Meacham wrote: > On Fri, Apr 18, 2008 at 08:36:42AM +0100, Simon Peyton-Jones wrote: >> Not allowing infix functions on the LHS would be a notable >> simplification. Constructors in patterns should still be infix of >> course: f (a :=: b) = ... > > I don't know, I think this will confuse things, especially for newbies, > people tend to say things like: > > a + b = foo > > as "a plus b is foo", and so would probably naturally write it in infix > form, it would be a source of confusion if the compiler didn't accept > it. > > I don't think saying ~ and ! are operators unless they > > 1. immediately followed by a '(', a letter, or an underscore > 2. are preceded by whitespace or BOL > > is that onerous. I don't like the idea of solving this in the lexical syntax, e.g. by the rules you gave above, it's just too ad-hoc. I think a better way to fix it is just to disallow infix declarations of !, ~ (and @ ?). Currently the grammar has: funlhs -> var apat {apat} | pati+1 varop(a,i) pati+1 | lpati varop(l,i) pati+1 | pati+1 varop(r,i) rpati | ( funlhs ) apat {apat} so we can use a restricted variant of varop that doesn't include !, ~ or @ (well, varop doesn't currently include ~ or @, but I assume we want it to - it would be similar to the way "hiding" is handled now). Incedentally I think we should use a different operator for array indexing, because ! is almost universally used to mean "strict" now: in bang patterns, strict datatype fields, and $!. See http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing Cheers, Simon From carette at mcmaster.ca Mon Apr 21 14:40:03 2008 From: carette at mcmaster.ca (Jacques Carette) Date: Mon Apr 21 14:38:08 2008 Subject: Haskell' - class aliases In-Reply-To: <480CD7BB.2040601@gmail.com> References: <480CD7BB.2040601@gmail.com> Message-ID: <480CDF83.3090904@mcmaster.ca> I tried to see the discussion that led to class aliases being rejected as a proposal, but could not find links on the Wiki. In fact, in Trac (#101) that proposal is still a 'maybe', but with no updates. Is there a competing proposal that got accepted? [Without a mechanism like class aliases, breaking up Num into a hierarchy of proper mathematical concepts becomes too unwieldly to be realistic. This is a real stumbling block for anyone trying to use the class system to encode fine-grained mathematical concepts.] Jacques From westondan at imageworks.com Mon Apr 21 14:45:02 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Apr 21 14:39:57 2008 Subject: Proposal: change to qualified operator syntax In-Reply-To: <480CD92A.4010408@gmail.com> References: <480CD92A.4010408@gmail.com> Message-ID: <480CE0AE.8040103@imageworks.com> Would it not be cleaner just to disallow infix notation of qualified operators altogether? It is clear enough to use "import qualified" or let or where clauses containing prefix notation to identify a qualified operator with an unqualified one: UGLY: m `Prelude.(>>=)` a `Prelude.(>>=)` b `Prelude.(>>=)` c CLEAR: m >>= a >>= b >>= c where (>>=) = Prelude.(>>=) [Personally, I prefer where to let for such purely syntactic details]. Dan Simon Marlow wrote: > Folks, > > Please comment on the following proposed change to qualified operator > syntax: > > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators > > Cheers, > Simon > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > > From ganesh.sittampalam at credit-suisse.com Mon Apr 21 15:37:07 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Apr 21 15:32:27 2008 Subject: Proposal: change to qualified operator syntax In-Reply-To: <480CD92A.4010408@gmail.com> References: <480CD92A.4010408@gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3335@ELON17P32002A.csfb.cs-group.com> > Please comment on the following proposed change to qualified operator > syntax: > http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators I like this change. It'll break a bit of my code, but I think it's worth it. The point of having infix operators is to write natural looking code, and qualifying them completely negates that benefit IMO. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ben_moseley at mac.com Mon Apr 21 15:39:03 2008 From: ben_moseley at mac.com (Ben Moseley) Date: Mon Apr 21 15:34:20 2008 Subject: Haskell' - class aliases In-Reply-To: <480CDF83.3090904@mcmaster.ca> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> Message-ID: <2E5D79FE-7BE5-43E2-9ED7-CE0D14CF90EC@mac.com> I would guess that the reason is that it hasn't been implemented yet... ...still it does seem to be a real shame if nothing in this area can make it into Haskell' .... (and it's not just Num .... Monad inheriting from Functor etc) ...it's a lot less sexy than something like TF, but I think it'd add a huge amount of value from the pragmatic point of view. --Ben On 21 Apr 2008, at 19:40, Jacques Carette wrote: > I tried to see the discussion that led to class aliases being > rejected as a proposal, but could not find links on the Wiki. In > fact, in Trac (#101) that proposal is still a 'maybe', but with no > updates. Is there a competing proposal that got accepted? > > [Without a mechanism like class aliases, breaking up Num into a > hierarchy of proper mathematical concepts becomes too unwieldly to > be realistic. This is a real stumbling block for anyone trying to > use the class system to encode fine-grained mathematical concepts.] > > Jacques > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From ganesh.sittampalam at credit-suisse.com Mon Apr 21 15:44:06 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Apr 21 15:39:45 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <480CDF3B.1090604@gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> > Incedentally I think we should use a different operator for array > indexing, because ! is almost universally used to mean "strict" > now: in bang patterns, strict datatype fields, and $!. See > http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing A lot of the discussion on that page pre-supposes that CompositionAsDot will be accepted. Does it really stand a chance? It would be enormously disruptive and uglify the language massively. Making it necessary to use non-ASCII characters would be a big practical problem, I think. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From marlowsd at gmail.com Mon Apr 21 16:36:33 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 16:31:29 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> Message-ID: <480CFAD1.7070205@gmail.com> Sittampalam, Ganesh wrote: > >> Incedentally I think we should use a different operator for array >> indexing, because ! is almost universally used to mean "strict" >> now: in bang patterns, strict datatype fields, and $!. See > >> http://hackage.haskell.org/trac/haskell-prime/wiki/ArrayIndexing > > A lot of the discussion on that page pre-supposes that CompositionAsDot > will be accepted. Does it really stand a chance? It would be enormously > disruptive and uglify the language massively. Making it necessary to > use non-ASCII characters would be a big practical problem, I think. Here are the possibilities for composition: 0. do nothing 1. use a Unicode operator for composition 2. require spaces around . as an operator 3. require spaces around all operators 4. use another ASCII operator for composition, e.g. <<< Nothing has been decided yet, but most of the committee tends to favour (2), with some expressing a slight preference for (0). We've pretty much ruled out (1) and (3) as too radical, and as you say using Unicode is still too impractical. There is some uncertainty about the precise details of (2), and thinking about that is what lead to my proposal about changing the syntax of qualified operators. Cheers, Simon From marlowsd at gmail.com Mon Apr 21 17:29:41 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 17:24:37 2008 Subject: Haskell' - class aliases In-Reply-To: <480CDF83.3090904@mcmaster.ca> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> Message-ID: <480D0745.4060701@gmail.com> Jacques Carette wrote: > I tried to see the discussion that led to class aliases being rejected > as a proposal, but could not find links on the Wiki. In fact, in Trac > (#101) that proposal is still a 'maybe', but with no updates. Is there > a competing proposal that got accepted? > > [Without a mechanism like class aliases, breaking up Num into a > hierarchy of proper mathematical concepts becomes too unwieldly to be > realistic. This is a real stumbling block for anyone trying to use the > class system to encode fine-grained mathematical concepts.] We want to get Haskell' done, and unfortunately that may mean rejecting some good proposals - in this case, class aliases is a fairly large feature that we don't have enough experience with yet, so it was dropped (I proposed dropping it recently to the committee, and no-one argued against). That's not to say it isn't worthwhile, and this certainly doesn't prevent it from being adopted in a future version of the standard. We'd like to see it implemented in GHC, too. BTW, by the end of this process I do want to make sure we've documented the rationale for all the decisions, so that future committees have a useful knowledge base to work from. Cheers, Simon From marlowsd at gmail.com Mon Apr 21 17:42:51 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 21 17:37:47 2008 Subject: Proposal: change to qualified operator syntax In-Reply-To: <480CE0AE.8040103@imageworks.com> References: <480CD92A.4010408@gmail.com> <480CE0AE.8040103@imageworks.com> Message-ID: <480D0A5B.5040309@gmail.com> Dan Weston wrote: > Would it not be cleaner just to disallow infix notation of qualified > operators altogether? It is clear enough to use "import qualified" or > let or where clauses containing prefix notation to identify a qualified > operator with an unqualified one: > > UGLY: > > m `Prelude.(>>=)` a > `Prelude.(>>=)` b > `Prelude.(>>=)` c > > > CLEAR: > > m >>= a >>= b >>= c > where (>>=) = Prelude.(>>=) > > [Personally, I prefer where to let for such purely syntactic details]. I did consider doing that, and it is certainly an option. The reasons I chose to allow the infix forms are: - if you add an import and introduce a name clash, then you want to resolve clashes by just modifying the names, not by refactoring code. The trick from your example above works, but it requires that all instances of (>>=) are in scope qualified, otherwise you get a shadowing warning. - it's cheap in terms of grammar and implementation. Cheers, Simon > Dan > > Simon Marlow wrote: >> Folks, >> >> Please comment on the following proposed change to qualified operator >> syntax: >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators >> >> Cheers, >> Simon >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> >> > From john at repetae.net Mon Apr 21 19:58:18 2008 From: john at repetae.net (John Meacham) Date: Mon Apr 21 19:53:11 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <480CFAD1.7070205@gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> <480CFAD1.7070205@gmail.com> Message-ID: <20080421235818.GT17560@sliver.repetae.net> On Mon, Apr 21, 2008 at 01:36:33PM -0700, Simon Marlow wrote: > 0. do nothing > 1. use a Unicode operator for composition > 2. require spaces around . as an operator > 3. require spaces around all operators > 4. use another ASCII operator for composition, e.g. <<< > > Nothing has been decided yet, but most of the committee tends to favour > (2), with some expressing a slight preference for (0). We've pretty much > ruled out (1) and (3) as too radical, and as you say using Unicode is still > too impractical. There is also the proposal to change the fixity of '$'. this would mean that '.' becomes a lot more common as f $ a $ b $ c would now be written f . a . b $ c John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Tue Apr 22 03:33:53 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Apr 22 03:28:48 2008 Subject: Haskell' - class aliases In-Reply-To: <480CDF83.3090904@mcmaster.ca> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> | I tried to see the discussion that led to class aliases being rejected | as a proposal, but could not find links on the Wiki. In fact, in Trac | (#101) that proposal is still a 'maybe', but with no updates. Is there | a competing proposal that got accepted? | | [Without a mechanism like class aliases, breaking up Num into a | hierarchy of proper mathematical concepts becomes too unwieldly to be | realistic. This is a real stumbling block for anyone trying to use the | class system to encode fine-grained mathematical concepts.] I think this is partly my fault for failing to implement the idea -- a full implementation is really a prerequisite for Haskell'. One reason I've failed to do so is because I have not come under enough pressure! If I thought there were dozens of people slavering at the chops for class aliases, that would put it more firmly on my radar. Ben is right to say that it's much easier than the type-function stuff, which is decidedly tricky. (Of course there nothing stopping someone else doing it, but GHC's typechecker is one of it's more richly-interconnected parts.) Perhaps you have all just been very polite, and waiting in quiet but unrequited hope. Is this the most up-to-date description of the proposal? http://repetae.net/recent/out/classalias.html I've just had another look, which threw up quite a few questions in my mind. I wonder what would be a good list to discuss it. Maybe this one is not bad, because it has people interested in Haskell innovation, regardless of whether it's a live Haskell' candidate? Simon From claus.reinke at talk21.com Tue Apr 22 12:16:55 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Apr 22 12:11:58 2008 Subject: DRAFT: Haskell' status update References: <480CD7BB.2040601@gmail.com> Message-ID: <015501c8a494$4c6f3250$d43b7ad5@cr3lt> > Nevertheless, the committee feels that we cannot have a Haskell' without > some way to resolve ambiguities when using multi-parameter type > classes, be it Functional Dependencies (FDs) or Type Families (TFs). agreed! > - "Haskell' alpha" will be a complete language specification, > including all the modifications and additions we want to make > to the language *except* for FDs or TFs. that should at least allow for some necessary progress. > - Haskell' will follow afterward, adding either FDs or TFs. that seems to suggest that Haskell' is going to be *the* standard, so it better be very good, and not leave out anything important, even if it is as recent as TFs. strangely, i never had such great expectations from this process - instead, i expected Haskell' to be *one in a series* of standards, documenting the current state, not any (supposedly) final state. it should have come out long ago, and should be well on its way to become obsolete in a few years (though not immediately, if possible). in line with those expectations, i'd be happy with a Haskell' beta, if it were to *standardise*, but *not prescribe* FDs and TFs and whatever other type system extensions have been in common use for a long time now. no Haskell' beta implementation would be required to implement either FDs or TFs or overlap resolution or closed classes or .. . but if i write {-# LANGUAGE TF #-} and the implementation doesn't complain, it'd better conform to the standard for TFs. currently, that is simply not the case, with LANGUAGE pragmas supported (and interpreted differently) by more than one implementation suggesting a *false* sense of standardisation and portability. > The motivation for this two-stage approach is that we can make progress > on all the other parts of the language without being blocked on the type > system, we can start work on implementing Haskell' alpha in our > compilers, users can start using the new standard, and we can gain some > experience with using it in practice. yet another option would be to standardise improvement as a means of reducing ambiguity, and simplification as a means of rewriting constraints, leaving open specific forms of specifying such improvements or simplifications - a bit like a language-standard "API" for adding features (perhaps there could even be a corresponding standard API for extending standard-conformant implementations) [1]. then there could be an addendum specifying FDs as one particular instance of enabling such improvements, and any implementation supporting {-# LANGUAGE FD #-} would have to conform to that addendum. and anyone wanting to support other forms of improvement (records, subtyping, ..) could program to that implementation extension API.. > Thanks for your patience :-) And rest assured that progress is being made! thanks for your update! (frankly, i had written off haskell prime;-) haskell prime is dead! long live haskell prime! claus [1] M. P. Jones. Simplifying and improving qualified types. In FPCA '95: Conference on Functional Programming Languages and Computer Architecture. ACM Press, 1995. http://web.cecs.pdx.edu/~mpj/pubs/improve.html From usenet at mkarcher.dialup.fu-berlin.de Tue Apr 22 13:28:27 2008 From: usenet at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Tue Apr 22 13:29:55 2008 Subject: Some clarity please! References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <87iqzqubo1.fsf@nmd9999.imr.no> Message-ID: In gmane.comp.lang.haskell.prime Aaron Denney wrote: > > Prelude> :i Ord > > class (Eq a) => Ord a where > > compare :: a -> a -> Ordering > > (<) :: a -> a -> Bool > > (>=) :: a -> a -> Bool > > (>) :: a -> a -> Bool > > (<=) :: a -> a -> Bool > > max :: a -> a -> a > > min :: a -> a -> a > > > > ..while all functions could be easily derived from 'compare'. Or from > > the Eq instance's (==) and (<), say. > > > > What is the reason for this? Efficiency? (Which couldn't be handled > > equally well by RULES?) Otherwise, it looks like an invitation for > > writing inconsistent instances. > > My impression (which may not be entirely accurate) is not primarily for > efficiency (though that is one reason), but for ease of implementation. [...] > max and min seem to have neither justification going for them, although > I suppose it's technically possible to write compare in terms of them > and (==). I am quite late to join this thread, but as I just read the thread about Conal's AddBounds where he had a very valid point for implementing min/max without resorting to <= or compare: min [] ys = [] min xs [] = [] min (x:xs) (y:ys) | cmp == LT = (x:xs) | cmp == GT = (y:ys) | cmp == EQ = x:min xs ys where cmp = compare x y This is a properly lazy implementation for min (the one in GHC's prelude is not), as it is able to calculate (take 5 $ min [1,2..] [1,2..]). This is not possible if min has to wait for compare or <= to compare the full lists before returning the head. Regards, Michael Karcher From simonmarhaskell at gmail.com Tue Apr 22 18:53:39 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 22 18:48:33 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" Message-ID: <20080422225339.GA27585@haskell.galois.com> Tue Apr 22 15:53:31 PDT 2008 Simon Marlow * add ""Make $ left associative, like application" M ./status.hs +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080422225331-8214f-8c2b7ec4a7666bfaa70b2514290172981bdebb50.gz From simonmarhaskell at gmail.com Tue Apr 22 19:10:50 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Apr 22 19:05:43 2008 Subject: patch applied (haskell-prime-status): point to the wiki for LiberalTypeSynonyms Message-ID: <20080422231050.GA28067@haskell.galois.com> Tue Apr 22 16:10:46 PDT 2008 Simon Marlow * point to the wiki for LiberalTypeSynonyms M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080422231046-8214f-e26c39dba6e6863c29bd03788c966b09f34e3430.gz From cdsmith at twu.net Tue Apr 22 19:13:57 2008 From: cdsmith at twu.net (Chris Smith) Date: Tue Apr 22 19:08:54 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" References: <20080422225339.GA27585@haskell.galois.com> Message-ID: On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote: > Tue Apr 22 15:53:31 PDT 2008 Simon Marlow > > * add ""Make $ left associative, like application" Is there a justification for this somewhere? I know it would break nearly every single piece of Haskell code I've ever written. As such, I'm biased toward thinking it's an extremely bad idea. From duncan.coutts at worc.ox.ac.uk Tue Apr 22 19:20:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Apr 22 19:15:34 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> Message-ID: <1208906440.27748.139.camel@localhost> On Tue, 2008-04-22 at 23:13 +0000, Chris Smith wrote: > On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote: > > Tue Apr 22 15:53:31 PDT 2008 Simon Marlow > > > > * add ""Make $ left associative, like application" > > Is there a justification for this somewhere? I know it would break > nearly every single piece of Haskell code I've ever written. As such, > I'm biased toward thinking it's an extremely bad idea. Indeed. I think it would at least be worth testing a bunch of packages from hackage and seeing how many break and when they do, how nice the fixes are. Surely there was a justification to having $ be the opposite associativity from application and not just a different precedence. Does anyone know what it was? Duncan From ndmitchell at gmail.com Tue Apr 22 19:20:49 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 22 19:15:40 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> Message-ID: <404396ef0804221620l607aa9bdy7d91e3c1fae350f2@mail.gmail.com> Hi Chris, > > * add ""Make $ left associative, like application" > > Is there a justification for this somewhere? I know it would break > nearly every single piece of Haskell code I've ever written. As such, > I'm biased toward thinking it's an extremely bad idea. >From the patch: + ,Issue "Make $ left associative, like application" [] + Undecided + Prelude i.e. its Undecided - not accepted. Like you, I would be mildly enraged if someone broke 100's of projects of mine simultaneously. Thanks Neil From marlowsd at gmail.com Tue Apr 22 19:21:18 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Apr 22 19:16:09 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> Message-ID: <480E72EE.5030703@gmail.com> Chris Smith wrote: > On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote: >> Tue Apr 22 15:53:31 PDT 2008 Simon Marlow >> >> * add ""Make $ left associative, like application" > > Is there a justification for this somewhere? I'm hoping someone will supply some. There seemed to be strong opinion on #haskell that this change should be made, but it might just have been a very vocal minority. > I know it would break > nearly every single piece of Haskell code I've ever written. As such, > I'm biased toward thinking it's an extremely bad idea. Absolutely. Given that, we'd need a *very* good reason to make the change. Cheers, Simon From dons at galois.com Tue Apr 22 19:24:03 2008 From: dons at galois.com (Don Stewart) Date: Tue Apr 22 19:19:07 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480E72EE.5030703@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: <20080422232403.GL27147@scytale.galois.com> marlowsd: > Chris Smith wrote: > >On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote: > >>Tue Apr 22 15:53:31 PDT 2008 Simon Marlow > >> > >> * add ""Make $ left associative, like application" > > > >Is there a justification for this somewhere? > > I'm hoping someone will supply some. There seemed to be strong opinion > on #haskell that this change should be made, but it might just have been > a very vocal minority. It's just Cale. -- Don From ndmitchell at gmail.com Tue Apr 22 19:24:59 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Apr 22 19:19:49 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480E72EE.5030703@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: <404396ef0804221624t3f3ff55cnf55575d11eee0ac0@mail.gmail.com> Hi > I'm hoping someone will supply some. There seemed to be strong opinion on > #haskell that this change should be made, but it might just have been a very > vocal minority. I think the feeling was that it encourages a slightly different style of programming, instead of: f $ g $ h x People should do: f . g . h $ x Then you can change the $ as suggested, and use it in other places. For a while I was persuaded it was a better style, but now I'm not convinced and have stuck to the first style. Either way, its a matter of style whose elegance is certainly not worth breaking all my code to improve. Thanks Neil From dan.doel at gmail.com Tue Apr 22 21:02:35 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Apr 22 20:57:30 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480E72EE.5030703@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: <200804222102.36020.dan.doel@gmail.com> On Tuesday 22 April 2008, Simon Marlow wrote: > I'm hoping someone will supply some. There seemed to be strong opinion > on #haskell that this change should be made, but it might just have been > a very vocal minority. These are the arguments off the top of my head: 1) Anything of the form: f $ g $ h $ x with right associative ($) can instead be written: f . g . h $ x where the associativity of ($) doesn't matter. It's not uncommon to want to peel off the end of such a pipeline to eliminate a point. For the second form, such a translation is: \x -> f . g . h $ x ==> f . g . h However: \x -> f $ g $ h $ x ==> f $ g $ h Is invalid, so one might argue that writing such pipelines with composition is a better habit to get into, as it allows easier cleanup of code in this way (if you like somewhat point-free code, that is). 2) Left associative ($) allows you to eliminate more parentheses. Per #1, any parentheses eliminated by right associative ($) can be eliminated by (.) and a single ($). However, left associative ($) allows, for instance: f (g x) (h y) ==> f $ g x $ h y 3) Left associative ($) is consistent with left associative ($!). The right associative version of the latter is inconvenient, because it only allows things to be (easily) strictly applied to the last argument of a function. Needing to strictly apply to other arguments gives rise to things like: (f $! x) y z ((f $! x) $! y) $! z Left associative, these are: f $! x $ y $ z f $! x $! y $! z There may be more arguments, but those are the ones I've heard that I can think of at the moment. #3 strikes me as the most likely to bite people (the other two are more stylistic issues), but I suppose I don't know the relative frequency of strict pipelines (f $! g $! x) versus strict applications at non-final arguments. And I suppose one has to weigh these arguments against breaking lots of code. Cheers, -- Dan From wnoise at ofb.net Tue Apr 22 22:56:10 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue Apr 22 22:51:17 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: On 2008-04-22, Simon Marlow wrote: > Chris Smith wrote: >> I know it would break >> nearly every single piece of Haskell code I've ever written. As such, >> I'm biased toward thinking it's an extremely bad idea. > > Absolutely. Given that, we'd need a *very* good reason to make the change. Surely we don't expect the majority of Haskell code to work unchanged as Haskell' code? -- Aaron Denney -><- From john at repetae.net Wed Apr 23 00:18:23 2008 From: john at repetae.net (John Meacham) Date: Wed Apr 23 00:13:12 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080423041823.GX17560@sliver.repetae.net> On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: > Is this the most up-to-date description of the proposal? > http://repetae.net/recent/out/classalias.html There were a few changes proposed in the discussion that followed my announcement that I wanted to make. The one I can remember now is getting rid of the 'alias' keyword since the equals sign unabiguously identifies it as an alias. I will dig through the archive to find the others.. > I've just had another look, which threw up quite a few questions in my > mind. I wonder what would be a good list to discuss it. Maybe this > one is not bad, because it has people interested in Haskell > innovation, regardless of whether it's a live Haskell' candidate? Sounds good to me. John -- John Meacham - ?repetae.net?john? From john at repetae.net Wed Apr 23 00:21:40 2008 From: john at repetae.net (John Meacham) Date: Wed Apr 23 00:16:29 2008 Subject: Haskell' - class aliases In-Reply-To: <20080423041823.GX17560@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> Message-ID: <20080423042140.GY17560@sliver.repetae.net> On Tue, Apr 22, 2008 at 09:18:23PM -0700, John Meacham wrote: > On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: > > Is this the most up-to-date description of the proposal? > > http://repetae.net/recent/out/classalias.html > > There were a few changes proposed in the discussion that followed my > announcement that I wanted to make. The one I can remember now is > getting rid of the 'alias' keyword since the equals sign unabiguously > identifies it as an alias. I will dig through the archive to find the > others.. Hmm.. looking at it again I think "my atrocious grammar" will be added to my list of things to fix. :) John -- John Meacham - ?repetae.net?john? From john at repetae.net Wed Apr 23 00:41:33 2008 From: john at repetae.net (John Meacham) Date: Wed Apr 23 00:36:32 2008 Subject: Some clarity please! In-Reply-To: References: <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <87iqzqubo1.fsf@nmd9999.imr.no> Message-ID: <20080423044133.GZ17560@sliver.repetae.net> On Tue, Apr 22, 2008 at 05:28:27PM +0000, Michael Karcher wrote: > I am quite late to join this thread, but as I just read the thread > about Conal's AddBounds where he had a very valid point for > implementing min/max without resorting to <= or compare: > > min [] ys = [] > min xs [] = [] > min (x:xs) (y:ys) > | cmp == LT = (x:xs) > | cmp == GT = (y:ys) > | cmp == EQ = x:min xs ys > where cmp = compare x y > > This is a properly lazy implementation for min (the one in GHC's > prelude is not), as it is able to calculate (take 5 $ min [1,2..] > [1,2..]). This is not possible if min has to wait for compare or <= to > compare the full lists before returning the head. In addition, you need special min and max functions to implement IEEE floating point properly. Of course, floating point is odd in general, but we should be correct when we can. John -- John Meacham - ?repetae.net?john? From bulat.ziganshin at gmail.com Wed Apr 23 01:32:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 01:31:10 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480E72EE.5030703@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: <1299323369.20080423093211@gmail.com> Hello Simon, Wednesday, April 23, 2008, 3:21:18 AM, you wrote: > I'm hoping someone will supply some. There seemed to be strong opinion > on #haskell that this change should be made, but it might just have been > a very vocal minority. i think this is some misinterpretation. haskell-prime should be, afaik, simple standardization of current software practices, more or less common subset of ghc/hugs language extensions. in particular, it should keep almost full bwd compatibility with H98 standard. it was haskell-2 to break up old things and build new perfect language from ground -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From john at repetae.net Wed Apr 23 01:41:22 2008 From: john at repetae.net (John Meacham) Date: Wed Apr 23 01:36:11 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1299323369.20080423093211@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1299323369.20080423093211@gmail.com> Message-ID: <20080423054122.GA17560@sliver.repetae.net> On Wed, Apr 23, 2008 at 09:32:11AM +0400, Bulat Ziganshin wrote: > > I'm hoping someone will supply some. There seemed to be strong opinion > > on #haskell that this change should be made, but it might just have been > > a very vocal minority. > > i think this is some misinterpretation. haskell-prime should be, > afaik, simple standardization of current software practices, more or > less common subset of ghc/hugs language extensions. in particular, it > should keep almost full bwd compatibility with H98 standard. it was > haskell-2 to break up old things and build new perfect language from > ground Haskell' will not be fully Haskell 98 compatible. But it won't break things too much hopefully. And no doubt compilers will have strategies for mixing h98 and h' code. John -- John Meacham - ?repetae.net?john? From bulat.ziganshin at gmail.com Wed Apr 23 01:43:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 01:41:32 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <20080423054122.GA17560@sliver.repetae.net> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1299323369.20080423093211@gmail.com> <20080423054122.GA17560@sliver.repetae.net> Message-ID: <1164475931.20080423094352@gmail.com> Hello John, Wednesday, April 23, 2008, 9:41:22 AM, you wrote: > Haskell' will not be fully Haskell 98 compatible. But it won't > break things too much hopefully. And no doubt compilers will have > strategies for mixing h98 and h' code. aside compilers, there are people, too. are we really want to put comments on each haskell snippet published - in which version of language it's written, for a such small benefit? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Apr 23 02:24:22 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 02:21:59 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <20080423054122.GA17560@sliver.repetae.net> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1299323369.20080423093211@gmail.com> <20080423054122.GA17560@sliver.repetae.net> Message-ID: <11075810.20080423102422@gmail.com> Hello John, Wednesday, April 23, 2008, 9:41:22 AM, you wrote: >> i think this is some misinterpretation. haskell-prime should be, >> afaik, simple standardization of current software practices, more or >> less common subset of ghc/hugs language extensions. > Haskell' will not be fully Haskell 98 compatible. in particular, h' should break H98 compatibility no more that existing ghc/hugs versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cgibbard at gmail.com Wed Apr 23 02:54:06 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Apr 23 02:48:56 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> 2008/4/22 Aaron Denney : > On 2008-04-22, Simon Marlow wrote: > > > Chris Smith wrote: > >> I know it would break > >> nearly every single piece of Haskell code I've ever written. As such, > >> I'm biased toward thinking it's an extremely bad idea. > > > > Absolutely. Given that, we'd need a *very* good reason to make the change. > > Surely we don't expect the majority of Haskell code to work unchanged as > Haskell' code? > And if we're not going to break things in Haskell', then when *are* we going to break them? Making all the little fiddly changes at once seems like a better plan than standardising on one thing and then changing things away from that in the implementations shortly afterwards. It also seems like a better plan than forking the language over what are essentially library issues. (This is a sort of minor one, but there other things, like 'fail', which I certainly would hope we don't just live with forever.) If the only goal of Haskell' is to standardise current practices, then I agree this change makes no sense, but it also seems not to make much sense to standardise a Prelude which people strongly want to change. Also, the Haskell 98 Prelude has already been reported on, and probably should continue to be supported in some way or another. By the way, as Don suggests, I do strongly advocate this change, and Dan Doel has already given a very nice summary of why. With regard to reason #1 in his list, I'd just like to add that due to the fact that (.) is an associative operator, a composition chain written in terms of (.) effectively has more subexpressions than one written in terms of ($), and is thus at least marginally easier to refactor and reason about. I've found that favouring (.) and being comfortable with expressing things in terms of function composition very much puts one in the right mindset for functional programming. - Cale From bulat.ziganshin at gmail.com Wed Apr 23 03:04:10 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 03:01:49 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> Message-ID: <447083336.20080423110410@gmail.com> Hello Cale, Wednesday, April 23, 2008, 10:54:06 AM, you wrote: > By the way, as Don suggests, I do strongly advocate this change, and i agree that the change by itself is reasonable, but fixing all the old issues and providing new beautiful language version should be project of its own. for example, i will propose raising precedences when there are no spaces around operator. this will significantly reduce amount of parentheses/$s: f a+b c*d f g(x) h(y) for now, wee need to standardize current haskell practice just for compilers interoperability and teaching purposes (noone wants to write book about ghc 6.8 or teach students to it) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cgibbard at gmail.com Wed Apr 23 03:26:49 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Apr 23 03:21:39 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <447083336.20080423110410@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <447083336.20080423110410@gmail.com> Message-ID: <89ca3d1f0804230026o3b836b89w96696cf5a8116f5f@mail.gmail.com> 2008/4/23 Bulat Ziganshin : > Hello Cale, > > > Wednesday, April 23, 2008, 10:54:06 AM, you wrote: > > > By the way, as Don suggests, I do strongly advocate this change, and > > i agree that the change by itself is reasonable, but fixing all the old > issues and providing new beautiful language version should be project > of its own. for example, i will propose raising precedences when there > are no spaces around operator. this will significantly reduce amount > of parentheses/$s: > > f a+b c*d > > f g(x) h(y) I'm not sure that I'm convinced about that one -- consider the simple function: f x = x^2 and the two programs: f x+y = (x+y)^2 f x + y = x^2 + y That's a pretty hard to see bug, and it sneaks right past the typechecker. I'm all for a certain amount of whitespace sensitivity, but that might be going too far. > for now, wee need to standardize current haskell practice just for > compilers interoperability and teaching purposes (noone wants to write > book about ghc 6.8 or teach students to it) > Well, my point is that if we can see these changes that we want to make to the libraries, it makes little sense to let people write those books and then change all the libraries out from under them a few months down the road. Maybe it's what we'll end up doing anyway, but it's worth considering. - Cale From ganesh.sittampalam at credit-suisse.com Wed Apr 23 03:46:45 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Apr 23 03:42:37 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> > but it also seems not to make much sense to standardise > a Prelude which people strongly want to change. I'm strongly against this change, both on its own merits - in most cases when there is a real argument being passed, I find chains of $s easier to think about than your alternative - but most importantly because it would be enormously disruptive. It's the kind of completely unnecessary thing that simply lends ammunition to the people that claim Haskell is an academic language unsuited to the real world. > Also, the Haskell 98 Prelude has already been reported on, and > probably should continue to be supported in some way or another. How would you propose supporting multiple preludes at once? I have a feeling most of the pieces are in place and it's just a question of documenting the "best practice" properly, but it needs to be done and we need to get experience with doing it and with a gradual migration strategy before we even consider this kind of change. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From bulat.ziganshin at gmail.com Wed Apr 23 03:58:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 03:56:04 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804230026o3b836b89w96696cf5a8116f5f@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <447083336.20080423110410@gmail.com> <89ca3d1f0804230026o3b836b89w96696cf5a8116f5f@mail.gmail.com> Message-ID: <1765841915.20080423115824@gmail.com> Hello Cale, Wednesday, April 23, 2008, 11:26:49 AM, you wrote: > f x+y = (x+y)^2 > f x + y = x^2 + y imho, it's easy to see what there are no spaces around + on first line, but there are spaces at the second. imho, it's just our habits - ignore spaces and split expression by operators actually, shift from usual style of f(x+y,z*t) to f (x+y) (z*t) was no less dramatic. i propose to go one step further and use spaces instead of brackets as one more way to control precedence. this idea born from my haskell programming practice - these additional parentheses are rather common and avoiding them will make program reading easier. but it needs to shift habits > That's a pretty hard to see bug, and it sneaks right past the > typechecker. I'm all for a certain amount of whitespace sensitivity, > but that might be going too far. my main point is that considering space-less operators as having larger priority is our natural habit. consider this: f a*b x+c imho, my interpretation of this expression sounds more natural than haskell's current one >> for now, wee need to standardize current haskell practice just for >> compilers interoperability and teaching purposes (noone wants to write >> book about ghc 6.8 or teach students to it) >> > Well, my point is that if we can see these changes that we want to > make to the libraries, it makes little sense to let people write those > books and then change all the libraries out from under them a few > months down the road. Maybe it's what we'll end up doing anyway, but > it's worth considering. unfortunately, it will be not a few months. there are many important things we may change in haskell. sometime ago it was said that haskell' will just standartize existing haskell (ghc/hugs) state and haskell 2 will be new, probably incompatible language. fixing just one oddity in haskell' will give us worst of both worlds - broken compatibility and lots of oddities still remaining -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cgibbard at gmail.com Wed Apr 23 04:06:08 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Apr 23 04:00:59 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> Message-ID: <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> 2008/4/23 Sittampalam, Ganesh : > > but it also seems not to make much sense to standardise > > a Prelude which people strongly want to change. > > I'm strongly against this change, both on its own merits > - in most cases when there is a real argument being passed, I find > chains of $s easier to think about than your alternative - > but most importantly because it would be enormously disruptive. > It's the kind of completely unnecessary thing that simply lends > ammunition to the people that claim Haskell is an academic > language unsuited to the real world. Well, try the alternative for a while. It was a little strange at first for me as well, but once you're used to it, it's extremely natural. I'd argue it even helps your thinking in other places, because you're constantly seeing composition chains (even if you still feel more comfortable thinking of them as application chains for a while), and this exceptionally simple change gets you into the spirit of thinking about functions as values to be combined, not just applied. I would argue that this mindset is an important one for functional programming, and anything which helps usher people toward it is a good thing. > > Also, the Haskell 98 Prelude has already been reported on, and > > probably should continue to be supported in some way or another. > > How would you propose supporting multiple preludes at once? I have > a feeling most of the pieces are in place and it's just a question > of documenting the "best practice" properly, but it needs to be done > and we need to get experience with doing it and with a gradual > migration strategy before we even consider this kind of change. > I agree that support for this is very important. It would be nice to simply be able to switch between base packages (and perhaps language options, like 98/H') with a single simple flag. I believe that migrating code will be quite a task regardless of the outcome here, but at least for the packages that are in Hackage, the system helpfully reports build failures, so we'll know where the breakages are, and roughly what's left to be done. - Cale From ndmitchell at gmail.com Wed Apr 23 04:18:52 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 23 04:13:44 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> Message-ID: <404396ef0804230118r17f160bfpce79bc4b17e8224b@mail.gmail.com> Hi > How would you propose supporting multiple preludes at once? Unhappy. The Haskell Prelude is more than just a standard library. Things like $, ., otherwise, >>= etc would be keywords in any other language. As such, you expect their meaning to be consistent. If you let other people define other Preludes you get very confused very quickly. I can just imagine otherwise = False sneaking in somewhere! I don't want to have to edit code and when I look at $ think "did Cale modify this code at any point in the past" :-) Thanks Neil From ganesh.sittampalam at credit-suisse.com Wed Apr 23 04:26:17 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Apr 23 04:21:59 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> > I believe that migrating code will be quite a task > regardless of the outcome here, NonDecreasing indentation and the removal of n+k patterns are the only accepted proposals I can see that might affect existing code. The former is already standard practice and the latter is unlikely to be that disruptive, as their use has been discouraged for some time. > but at least for > the packages that are in Hackage, the system helpfully > reports build failures, so we'll know where the breakages > are, and roughly what's left to be done. There's plenty of code out there that doesn't have the benefit of a vigilant user community ready to spring into action. For example, Credit Suisse has several tens of thousands of lines of code written by internal users who are not Haskell experts, and it would be rather hard to explain to them that they needed to go through it all and fix it. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From duncan.coutts at worc.ox.ac.uk Wed Apr 23 05:08:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 05:03:28 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804222102.36020.dan.doel@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> Message-ID: <1208941715.27748.153.camel@localhost> On Tue, 2008-04-22 at 21:02 -0400, Dan Doel wrote: > 3) Left associative ($) is consistent with left associative ($!). The right > associative version of the latter is inconvenient, because it only allows > things to be (easily) strictly applied to the last argument of a function. What about having ! as a left associative strict apply operator? f !x !y !z Isn't there already a proposal along these lines? There is certainly a proposal to stop using ! for array indexing. Duncan From josef.svenningsson at gmail.com Wed Apr 23 05:09:26 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Wed Apr 23 05:04:18 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804222102.36020.dan.doel@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> Message-ID: <8dde104f0804230209r19ed0d7y965a04cb94d99da@mail.gmail.com> First I would like to remind everyone of Wadler's law of language design: http://www.haskell.org/haskellwiki/Wadlers_Law Having said that I'm now going to argue for yet another color for the bike shed. I was a little surprised by the list of motivations for changing the fixity of $ because it didn't contain the one argument I was in fact expecting to hear. 0) $ was introduced as a combinator for function application. Therefore we might expect that whenever we have a function application we can stick a $ in there. But this is not the case. Consider the following expression: f x y There are two applications here and if $ behaved like function application we would be able to write: f $ x $ y But as it is now this expression means something completely different. I expected this discrepancy between function application and $ to be the major reason for changing the fixity. That being said, this change would break a lot of my code as well and I'm not a big fan of it. Cheers, Josef On Wed, Apr 23, 2008 at 3:02 AM, Dan Doel wrote: > On Tuesday 22 April 2008, Simon Marlow wrote: > > I'm hoping someone will supply some. There seemed to be strong opinion > > on #haskell that this change should be made, but it might just have been > > a very vocal minority. > > These are the arguments off the top of my head: > > 1) Anything of the form: > > f $ g $ h $ x > > with right associative ($) can instead be written: > > f . g . h $ x > > where the associativity of ($) doesn't matter. It's not uncommon to want to > peel off the end of such a pipeline to eliminate a point. For the second > form, such a translation is: > > \x -> f . g . h $ x ==> f . g . h > > However: > > \x -> f $ g $ h $ x ==> f $ g $ h > > Is invalid, so one might argue that writing such pipelines with composition is > a better habit to get into, as it allows easier cleanup of code in this way > (if you like somewhat point-free code, that is). > > 2) Left associative ($) allows you to eliminate more parentheses. Per #1, any > parentheses eliminated by right associative ($) can be eliminated by (.) and > a single ($). However, left associative ($) allows, for instance: > > f (g x) (h y) ==> f $ g x $ h y > > 3) Left associative ($) is consistent with left associative ($!). The right > associative version of the latter is inconvenient, because it only allows > things to be (easily) strictly applied to the last argument of a function. > Needing to strictly apply to other arguments gives rise to things like: > > (f $! x) y z > ((f $! x) $! y) $! z > > Left associative, these are: > > f $! x $ y $ z > f $! x $! y $! z > > There may be more arguments, but those are the ones I've heard that I can > think of at the moment. #3 strikes me as the most likely to bite people (the > other two are more stylistic issues), but I suppose I don't know the relative > frequency of strict pipelines (f $! g $! x) versus strict applications at > non-final arguments. > > And I suppose one has to weigh these arguments against breaking lots of code. > > Cheers, > -- Dan > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From duncan.coutts at worc.ox.ac.uk Wed Apr 23 05:17:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 05:12:20 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480E72EE.5030703@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> Message-ID: <1208942252.27748.160.camel@localhost> On Tue, 2008-04-22 at 16:21 -0700, Simon Marlow wrote: > Chris Smith wrote: > > On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote: > >> Tue Apr 22 15:53:31 PDT 2008 Simon Marlow > >> > >> * add ""Make $ left associative, like application" > > > > Is there a justification for this somewhere? > > I'm hoping someone will supply some. There seemed to be strong opinion > on #haskell that this change should be made, but it might just have been > a very vocal minority. It true that (f $ g $ h $ x) might be nicer written (f . g . h $ x) but I've always thought the point of $ is for things like withSomeResource foo $ withSomeOtherThing bar $ yetAnotherBlockStructured thing $ ... Does that work? Or withSomeResource foo $ \x -> withSomeOtherThing bar $ \y -> yetAnotherBlockStructured thing $ \z -> Or does that case still work? There must have been some justification for the original design or was it just f $ g $ h $ x ? Duncan From dan.doel at gmail.com Wed Apr 23 05:42:20 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Apr 23 05:37:14 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1208942252.27748.160.camel@localhost> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> Message-ID: <200804230542.21570.dan.doel@gmail.com> On Wednesday 23 April 2008, Duncan Coutts wrote: > withSomeResource foo $ > withSomeOtherThing bar $ > yetAnotherBlockStructured thing $ ... > > Does that work? This wouldn't work, you'd have to rewrite it as: withSomeResource foo . withSomeOtherThing bar . yetAnotherBlockStructured thing $ ... But it seems like your second example is more likely to come up for 'with' type blocks: > Or > > withSomeResource foo $ \x -> > withSomeOtherThing bar $ \y -> > yetAnotherBlockStructured thing $ \z -> That should work, because '\x ->' extends to the end of the expression. Similarly: iWantMonadicValues $ do foo bar iAlsoWantMonadicStuff $ do ... still works. -- Dan From bulat.ziganshin at gmail.com Wed Apr 23 05:55:50 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 05:54:28 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804230542.21570.dan.doel@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> Message-ID: <1056838947.20080423135550@gmail.com> Hello Dan, Wednesday, April 23, 2008, 1:42:20 PM, you wrote: > This wouldn't work, you'd have to rewrite it as: > withSomeResource foo . > withSomeOtherThing bar . > yetAnotherBlockStructured thing $ ... it is very inconvenient - we should use either . or $ depending on that it's last block or not. imagine all the changes when editing the code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dan.doel at gmail.com Wed Apr 23 07:03:10 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Apr 23 06:58:02 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1056838947.20080423135550@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: <200804230703.10889.dan.doel@gmail.com> On Wednesday 23 April 2008, Bulat Ziganshin wrote: > Hello Dan, > > Wednesday, April 23, 2008, 1:42:20 PM, you wrote: > > This wouldn't work, you'd have to rewrite it as: > > > > withSomeResource foo . > > withSomeOtherThing bar . > > yetAnotherBlockStructured thing $ ... > > it is very inconvenient - we should use either . or $ depending on > that it's last block or not. imagine all the changes when editing the > code Well, that may be inconvenient, but I don't know how much such block structured code is actually a composition of such functions. Off the top of my head, I'd expect most to involve lambdas or dos: forM l $ \e -> ... State $ \s -> ... (see also Reader, Cont, ...) runST $ do ... (or 'flip runM arg' for most monads, I suppose) callCC $ \k -> ... (shift) forever $ do ... withResource $ \r -> ... local f $ do ... Which still work with the flipped associativity. The one oddity I noticed looking at random code of mine is reset in Cont(T), which might currently be used like: reset $ forM l $ \e -> ... for inverting loops. It would have to become: reset . forM l $ \e -> ... Which might be a little weird (of course, in CC-delcont, that's reset $ \p -> forM l $ \e -> ... so it's moot there, but I suppose this affects all the functions that rely on 'do' to use repeated ($)s). My code may well be abnormal, though (certainly, my infatuation with continuations probably is :)). When I do have composition pipelines that don't fit on one line (like the initial example), I think I tend to write them like this: pipe = foo . bar . baz . quux $ quuux Which lets you slip new things in pretty naturally, I think. There may be a lot of code out there that that all doesn't work for, though. I don't know. -- Dan From apfelmus at quantentunnel.de Wed Apr 23 07:41:35 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Apr 23 07:36:38 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804222102.36020.dan.doel@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> Message-ID: Dan Doel wrote: > 3) Left associative ($) is consistent with left associative ($!). > > (f $! x) y z > ((f $! x) $! y) $! z > > Left associative, these are: > > f $! x $ y $ z > f $! x $! y $! z Nice! Subconsciously, the fact that ($!) is currently not left associative has always bitten me. In the light of Cale's plan to make (.) equivalent to fmap , there is also the option to redefine ($) to mean fmap . This would eliminate the need for a special <$> for applicative functors. Note that setting (.) or ($) = fmap subsumes function application, because we have fmap :: (a -> b) -> a -> b for the /identity functor/. In other words, the current ($) and (.) are just special cases of the general fmap . Unfortunately, the identity functor currently can't be overloaded, although I think it would be unambiguous. Regards, apfelmus From carette at mcmaster.ca Wed Apr 23 10:58:10 2008 From: carette at mcmaster.ca (Jacques Carette) Date: Wed Apr 23 10:53:48 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <480F4E82.4060407@mcmaster.ca> In all honesty what I want is a solution to the problems clearly outlined in the first two sections of his proposal. People may not be clamouring for this (yet), but that maybe simply because they've gotten used to the de facto Haskell style of giant type classes and never seriously asking themselves if maybe there was a better way to do things. Certainly the issues that 1) Num needs broken up, and 2) Functor and Monad should be related, do come up relatively frequently. John's example for 'Lattice' is really spot-on, that is exactly what 1) a developer for an advanced class wants 2) exactly what a developer would like to provide to users (ie the coarser Lattice and BoundedLattice). In my mind that defines the problem to be solved quite nicely. Which gets us to: Simon Peyton-Jones wrote: > I've just had another look, which threw up quite a few questions in my mind. I wonder what would be a good list to discuss it. Maybe this one is not bad, because it has people interested in Haskell innovation, regardless of whether it's a live Haskell' candidate? > I wrote the above because there really are two very different kinds of questions: requirements and design. If there is first a solid agreement on requirements, then it is much simpler to tweak the design. [Motherhood stuff, sorry, but sometimes a reminder of such things is useful]. So in what class are your questions? Since we are talking requirements: to properly follow Parnas' ideas on good design, we should ask ourselves what are the likely future changes in this area. I know of one extension which will definitely be wanted in the future: renamings. For example, mathematicians frequently switch between additive and multiplicative notations for Groups. So one would want to ``inherit'' from a class but allow for a name change at the same time. In effect, one can already to this, ie class Foo a where foo :: a class Foo a => Bar a where bar :: a bar = foo However the difference is that the equility bar = foo is not known intensionally, ie not available to the compiler as something that can be reasoned with. I do believe that that will be an important future consideration. [I could be wrong about how the status of such equalities in the language definition, but I must admit I would be surprised if it were otherwise]. Note that such 'renamings' are a common operation available in "algebraic specification languages" of various kinds. And type classes really are much closer to (algebraic) specifications than anything else, so I do believe that one can learn what are the 'useful operations' from those languages. Proper design then means that a current solution allows for a solution of the above in the future, and definitely does not make such a solution impossible. The solution does not have to be done (either designed, much less implemented) now. [Teaching SE does seem to infect one's mind, doesn't it?] Jacques From cgibbard at gmail.com Wed Apr 23 12:06:42 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Apr 23 12:01:32 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> Message-ID: <89ca3d1f0804230906j2588becaq523e74dca346954b@mail.gmail.com> 2008/4/23 apfelmus : > Dan Doel wrote: > > Note that setting (.) or ($) = fmap subsumes function application, because > we have > > fmap :: (a -> b) -> a -> b > > for the /identity functor/. In other words, the current ($) and (.) are > just special cases of the general fmap . Unfortunately, the identity > functor currently can't be overloaded, although I think it would be > unambiguous. > Unfortunately, it would be quite ambiguous -- the identity functor overlaps with basically any other. Consider the case: reverse . [[1,2,3],[4,5]] which if (.) is fmap would normally mean [[3,2,1],[5,4]], but if the identity functor is used instead would mean [[4,5],[1,2,3]]. - Cale From simonmarhaskell at gmail.com Wed Apr 23 12:47:07 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Apr 23 12:42:00 2008 Subject: patch applied (haskell-prime-status): wiki link for the $ issue Message-ID: <20080423164707.GA17916@haskell.galois.com> Wed Apr 23 09:47:02 PDT 2008 Simon Marlow * wiki link for the $ issue M ./status.hs -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080423164702-8214f-f38f4a62db63708da38c8cabdb65bc8af8aea58c.gz From marlowsd at gmail.com Wed Apr 23 12:49:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 23 12:43:53 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804222102.36020.dan.doel@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> Message-ID: <480F687D.5040308@gmail.com> Dan Doel wrote: > On Tuesday 22 April 2008, Simon Marlow wrote: >> I'm hoping someone will supply some. There seemed to be strong opinion >> on #haskell that this change should be made, but it might just have been >> a very vocal minority. > > These are the arguments off the top of my head: Thanks, I've put these points, and Josef's point, on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity (I should point out that I'm personally *not* in favour of this change, just making sure the arguments are documented) Cheers, Simon From marlowsd at gmail.com Wed Apr 23 12:52:11 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 23 12:47:02 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1208941715.27748.153.camel@localhost> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <1208941715.27748.153.camel@localhost> Message-ID: <480F693B.5080509@gmail.com> Duncan Coutts wrote: > On Tue, 2008-04-22 at 21:02 -0400, Dan Doel wrote: > >> 3) Left associative ($) is consistent with left associative ($!). The right >> associative version of the latter is inconvenient, because it only allows >> things to be (easily) strictly applied to the last argument of a function. > > What about having ! as a left associative strict apply operator? > > f !x !y !z > > Isn't there already a proposal along these lines? There is certainly a > proposal to stop using ! for array indexing. The problem with this is that f !x y would associate differently in an expression than it does on the left hand side of an equation, where ! is the prefix bang-pattern operator. To make this consistent we'd have to make ! a prefix operator in expressions, or give it the same precedence as function application; both mean a new extension. Cheers, Simon From marlowsd at gmail.com Wed Apr 23 13:32:24 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 23 13:27:16 2008 Subject: The monomorphism restriction and monomorphic pattern bindings Message-ID: <480F72A8.2080401@gmail.com> Folks, The current proposal on the table for what to do about the monomorphism restriction (henceforth MR) is * remove the MR entirely * adopt Monomorphic Pattern Bindings (MPB) Right now, the committee is almost uniformly in favour of dropping the MR, and most of us are coming round to the idea of MPB. Since this area has historically been difficult to achieve a concensus on, I'm excited that we appear to be close to making a decision, and a good one at that! The arguments for removing the MR are pretty well summarised on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphismRestriction You can read about MPB here: http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings GHC has implemented MPB by default (i.e. we deviate slightly from Haskell 98) since 6.8.1. The nice thing about the combination of removing MR and adopting MPB is that we retain a way to explicitly declare monomorphic bindings. These are monomorphic bindings: ~x = e x@_ = e or if you don't mind a strict binding: !x = e. The wiki points out that (x) = e would also be monomorphic, but arguably this is in poor taste since we expect (x) to mean the same as x everywhere. Cheers, Simon From cdsmith at twu.net Wed Apr 23 14:16:35 2008 From: cdsmith at twu.net (Chris Smith) Date: Wed Apr 23 14:11:41 2008 Subject: Meta-point: backward compatibility Message-ID: There appears to be some question as to the backward compatibility goals of Haskell'. Perhaps it's worth bringing out into the open. >From conversations I've had and things I've read, I've always gathered that the main goal of Haskell' is to address the slightly embarrassing fact that practically no one actually writes code in Haskell, if by Haskell we mean the most recent completed language specification. This obviously argues strongly for a high degree of backward compatibility. On the other hand, I am assuming everyone agrees that we don't want to replicate Java, which (in my view, anyway) is rapidly becoming obsolete because of an eagerness to make the language complex, inconsistent, and generally outright flawed in order to avoid even the most unlikely of broken code. -- Chris From apfelmus at quantentunnel.de Wed Apr 23 14:17:25 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Apr 23 14:12:33 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804230906j2588becaq523e74dca346954b@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <89ca3d1f0804230906j2588becaq523e74dca346954b@mail.gmail.com> Message-ID: Cale Gibbard wrote: > apfelmus wrote: >> >> Unfortunately, the identity functor currently can't be overloaded, >> although I think it would be unambiguous. >> > > Unfortunately, it would be quite ambiguous -- the identity functor > overlaps with basically any other. Consider the case: > > reverse . [[1,2,3],[4,5]] > > which if (.) is fmap would normally mean [[3,2,1],[5,4]], but if the > identity functor is used instead would mean [[4,5],[1,2,3]]. Whoops, what I did think here? I somehow thought that the argument of the function applied ( reverse in this case) would fix the functor. But this only works if the function is monomorphic: (reverse :: [[Int]] -> [[Int]]) . [[1,2,3],[4,5]] (reverse :: [Int] -> [Int]) . [[1,2,3],[4,5]] not if it's polymorphic. Regards, apfelmus From johan.tibell at gmail.com Wed Apr 23 14:50:36 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Apr 23 14:45:38 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: Message-ID: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> An interesting question. What is the goal of Haskell'? Is it to, like Python 3000, fix warts in the language in an (somewhat) incompatible way or is it to just standardize current practice? I think we need both, I just don't know which of the two Haskell' is. -- Johan On Wed, Apr 23, 2008 at 2:16 PM, Chris Smith wrote: > There appears to be some question as to the backward compatibility goals > of Haskell'. Perhaps it's worth bringing out into the open. > > >From conversations I've had and things I've read, I've always gathered > that the main goal of Haskell' is to address the slightly embarrassing > fact that practically no one actually writes code in Haskell, if by > Haskell we mean the most recent completed language specification. This > obviously argues strongly for a high degree of backward compatibility. > > On the other hand, I am assuming everyone agrees that we don't want to > replicate Java, which (in my view, anyway) is rapidly becoming obsolete > because of an eagerness to make the language complex, inconsistent, and > generally outright flawed in order to avoid even the most unlikely of > broken code. > > -- > Chris > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From flippa at flippac.org Wed Apr 23 14:53:54 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Apr 23 14:47:43 2008 Subject: Meta-point: backward compatibility In-Reply-To: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: On Wed, 23 Apr 2008, Johan Tibell wrote: > An interesting question. What is the goal of Haskell'? Is it to, like > Python 3000, fix warts in the language in an (somewhat) incompatible > way or is it to just standardize current practice? I think we need > both, I just don't know which of the two Haskell' is. > Current practice often involves removing certain warts anyway - the MR being a great example. -- flippa@flippac.org Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recomendations. Ivanova is God. And, if this ever happens again, Ivanova will personally rip your lungs out! From bulat.ziganshin at gmail.com Wed Apr 23 14:57:35 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 14:56:11 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: <1489447818.20080423225735@gmail.com> Hello Philippa, Wednesday, April 23, 2008, 10:53:54 PM, you wrote: > Current practice often involves removing certain warts anyway - the MR > being a great example. it's already in ghc for a years and doesn't affect too much code. we need a solid base of a language to write to, to learn, to popularize. and to develop next, more advanced language versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Wed Apr 23 15:03:45 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Apr 23 14:58:34 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: <90889fe70804231203x9d7dc9k9fd4bd860fa76480@mail.gmail.com> On Wed, Apr 23, 2008 at 2:53 PM, Philippa Cowderoy wrote: > Current practice often involves removing certain warts anyway - the MR > being a great example. I was more thinking of things like removing fail from the Monad class and fixing the I/O libraries to use Unicode, etc. From lennart at augustsson.net Wed Apr 23 15:38:50 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Apr 23 15:33:39 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480F687D.5040308@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <480F687D.5040308@gmail.com> Message-ID: I my opinion, anyone who suggest changing the associativity of $ is insane. Or just hating every Haskell user. Changing $ would make virtually every Haskell program uncompilable. Just pick some other (Unicode?) operator, but leave $ alone. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20080423/7f8a337d/attachment.htm From bulat.ziganshin at gmail.com Wed Apr 23 15:46:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 15:45:12 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <480F687D.5040308@gmail.com> Message-ID: <1306277192.20080423234636@gmail.com> Hello Lennart, Wednesday, April 23, 2008, 11:38:50 PM, you wrote: > Just pick some other (Unicode?) operator, but leave $ alone. good said. i have my own version of &&/|| which i love more but they are called &&&/||| -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Wed Apr 23 16:05:29 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 23 16:00:17 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480F693B.5080509@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <1208941715.27748.153.camel@localhost> <480F693B.5080509@gmail.com> Message-ID: <20080423200528.GA26970@matrix.chaos.earth.li> On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote: > > The problem with this is that > > f !x y > > would associate differently in an expression than it does on the left > hand side of an equation, where ! is the prefix bang-pattern operator. > To make this consistent we'd have to make ! a prefix operator in > expressions But it's not a prefix operator in the sense that we could define it (in a hypothetical language that allowed us to define prefix operators), it's actually syntax, which makes it much less appealing to me. Thanks Ian From iavor.diatchki at gmail.com Wed Apr 23 16:15:19 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Apr 23 16:10:07 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <480F72A8.2080401@gmail.com> References: <480F72A8.2080401@gmail.com> Message-ID: <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> Hello, Removing the MR seems reasonable. I am a little less certain about the MPB rule though. I suspect that, as the wiki page points out, many uses of pattern bindings are monomorphic but still, there seem to be a number of examples on the wiki where people have run into this problem. So I am not sure that the conclusion that nobody has noticed the change is valid. I do believe that you can probably work around the problem in many situations but the question in my mind is "why should we have to work around stuff when we have a system that already works?" In other words, what problem do MBPs solve? I should also point out that if we were to adopt the MBP rule, we would have to adjust the definition of what pattern bindings mean. For example, I think that this is how things are desugared at the moment: (x,y) = e becomes new_var = e x = case new_var of (v,_) -> v y = case new_var of (_,v) -> v It seems that under MBP the second program is not equivalent to the first because it is more polymorphic. -Iavor On Wed, Apr 23, 2008 at 10:32 AM, Simon Marlow wrote: > Folks, > > The current proposal on the table for what to do about the monomorphism > restriction (henceforth MR) is > > * remove the MR entirely > * adopt Monomorphic Pattern Bindings (MPB) > > Right now, the committee is almost uniformly in favour of dropping the MR, > and most of us are coming round to the idea of MPB. Since this area has > historically been difficult to achieve a concensus on, I'm excited that we > appear to be close to making a decision, and a good one at that! > > The arguments for removing the MR are pretty well summarised on the wiki: > > http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphismRestriction > > You can read about MPB here: > > > http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings > > GHC has implemented MPB by default (i.e. we deviate slightly from Haskell > 98) since 6.8.1. > > The nice thing about the combination of removing MR and adopting MPB is > that we retain a way to explicitly declare monomorphic bindings. These are > monomorphic bindings: > > ~x = e > x@_ = e > > or if you don't mind a strict binding: !x = e. The wiki points out that > > (x) = e > > would also be monomorphic, but arguably this is in poor taste since we > expect (x) to mean the same as x everywhere. > > Cheers, > Simon > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From niklas.broberg at gmail.com Wed Apr 23 16:42:02 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Apr 23 16:36:50 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1056838947.20080423135550@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: When I first saw this thread, my gut response was "Aw gawds no, don't touch my $ !!" I love $, I use it all the time, it really helps making code more readable and more nicely structured. I would really hate for someone to take that away from me. So when I came across this: > > This wouldn't work, you'd have to rewrite it as: > > > withSomeResource foo . > > withSomeOtherThing bar . > > yetAnotherBlockStructured thing $ ... > > > it is very inconvenient - we should use either . or $ depending on > that it's last block or not. imagine all the changes when editing the > code ... my initial response to it was yeah, Bulat is right, that's rather inconsistent, and it would mean a lot of changes when editing (and it's ugly too!). But then I started questioning my own motives. What changes would that be? Changing a . to a $ if I decided to remove the previous last piece of the "pipeline"? Doesn't seem too hairy, and I have to do far worse than that already when refactoring. Inconsistent? Doesn't it actually make perfect sense that the actual application of the "pipeline" of functions to some value is handled differently? Like Cale said, wouldn't it actually be a Good Thing that we treated these things as composition chains instead of application chains? And I could no longer defend my own position, and so I started thinking for real. Refactoring doesn't become harder with this suggestion - it becomes easier in general, just as Dan points out in #1. And I know I've been bitten by his #2 a bunch of times, even if I haven't realized the source of the problem until I read this thread. It's messy having to use a lot of parenthesis just because some argument to a function isn't the last one, and I've found myself wishing for a way to get rid of them. I know I have at times refactored my function definitions, switching their arguments around just to get the one that would need the parenthesis to be the last one. So I dug through some of my code, picking large modules at random. As I said I use $ *a lot*, anywhere that I can get away with it. In the first 10 modules I looked at, I found one (1) place where I would need to change a $ to a . to make it work. So I went to look at a bigger module, and in what is possibly my largest self-contained module (1800 loc including comments) I had 211 uses of $, and I would have had to change 23 of them into . instead to make it work with a left-associative version. All the ones where the left operand is just a function (like return) will still work. All the ones that are followed by a '\x -> ...' will still work. All the ones followed by a 'do ...' will still work. On the other hand, I found 10 places where I could immediately have gotten rid of some extra parentheses, and that just by searching for uses of fmap in the code! It should be said though that changing the associativity of $ doesn't make all code nice and clean. Consider for instance f (g (h x)) (k y) We could change that into one of f $ g (h x) $ k y f (g $ h x) $ k y but not get rid of the parenthesis altogether, i.e. uses of $ for different applications won't mix. But with right-associative $, the second one would be our only option, so at least we're no worse off than before, and perhaps it could be argued we are better off (in this kind of situation). I think it is reasonable to look closely at the motivations for wanting to retain the $ as is. Looking through this thread, I can find only a single complaint raised (albeit an important one), namely backwards compatibility. Yes, such a change would likely break quite a few my modules. But like Cale, I would never have expected H' to be fully backwards compatible with H98, and thus there would have to be some way to migrate anyway. This one seems pretty simple, just let the old Prelude be Haskell98.Prelude and import that in old code. Of course changes that break backwards compatibility should not be made frivolously, but I find it hard to buy having only that as an argument for a change that otherwise seems highly reasonable. We live in a beautiful statically typed world. If the proposed change was such that existing code would still compile, but with a different behavior, it would be really dangerous. That's clearly not the case here, there's no way that code that uses $-chaining would still compile if the associativity was changed, and any other use of $ would still compile and work as before. The type checker is there to help us, and it's literally a moment's work to clean up existing code to meet these standards. (And it's even faster to import Haskell98.Prelude if you're lazy). So come on, give me an argument for why $ should be right-associative instead of complaining about broken code (that I argue won't break even half as bad as some of you would have it). Is there really no reason at all why right-associative is to be preferred over left-associative? And if there is, why don't we hear it? Are you truly arguing this because you think there's a problem with left-associative $, or are you simply arguing because you want to stay with what you're used to? "The ability to think differently today from yesterday distinguishes the wise man from the stubborn." - John Steinbeck Cheers, /Niklas ps. Though to be honest I really don't see why we don't simply add another operator instead of changing an existing one... :-) From niklas.broberg at gmail.com Wed Apr 23 16:52:18 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Apr 23 16:47:06 2008 Subject: Meta-point: backward compatibility In-Reply-To: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: > An interesting question. What is the goal of Haskell'? Is it to, like > Python 3000, fix warts in the language in an (somewhat) incompatible > way or is it to just standardize current practice? I think we need > both, I just don't know which of the two Haskell' is. I would hope it is both. Some changes simply cannot become current practice since they would not be compatible with existing code, and the only place that such changes *could* be made is in a new language version. Like you say, fail in the Monad class is one such issue that would not be backwards compatible, and couldn't become a current practice without some help. Chicken or egg first? Cheers, /Niklas From wnoise at ofb.net Wed Apr 23 17:01:38 2008 From: wnoise at ofb.net (Aaron Denney) Date: Wed Apr 23 16:56:39 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> Message-ID: On 2008-04-23, Sittampalam, Ganesh wrote: > There's plenty of code out there that doesn't have the benefit > of a vigilant user community ready to spring into action. For > example, Credit Suisse has several tens of thousands of lines of > code written by internal users who are not Haskell experts, and > it would be rather hard to explain to them that they needed to > go through it all and fix it. What makes them need to update to Haskell' instead of sticking with Haskell '98? -- Aaron Denney -><- From bulat.ziganshin at gmail.com Wed Apr 23 16:59:29 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Apr 23 16:58:03 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: <1067130901.20080424005929@gmail.com> Hello Niklas, Thursday, April 24, 2008, 12:42:02 AM, you wrote: > But then I started questioning my own motives. What changes would that > be? Changing a . to a $ if I decided to remove the previous last piece > of the "pipeline"? Doesn't seem too hairy, and I have to do far worse > than that already when refactoring. it's not refactoring! it's just adding more features - exception handler, progress indicator, memory pool and so on. actually, code blocks used as a sort of RAII for Haskell. are you wanna change all those ';' when you add new variable to your C++ code? bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do doChunks arcsize sector_size $ \bytes -> do uiWithProgressIndicator command arcsize $ do or handleCtrlBreak (ignoreErrors$ fileRemove arcname_fixed) $ do bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ \new_archive -> do withJIT (fileOpen =<< originalURL originalName arcname) fileClose $ \original' -> do is just two examples from my code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Wed Apr 23 17:07:38 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Apr 23 17:02:26 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: <90889fe70804231407s3e0529a7g556ac1d1732c93ec@mail.gmail.com> On Wed, Apr 23, 2008 at 4:52 PM, Niklas Broberg wrote: > I would hope it is both. Some changes simply cannot become current > practice since they would not be compatible with existing code, and > the only place that such changes *could* be made is in a new language > version. Like you say, fail in the Monad class is one such issue that > would not be backwards compatible, and couldn't become a current > practice without some help. Chicken or egg first? You're of course right. Haskell' could be both. It probably should be as the next Haskell standard (after Haskell') will probably be several years in the future. It would be a shame to wake up the day after GHC fully implements Haskell' and notice that nothing has changed and my old annoyances are still there. -- Johan From niklas.broberg at gmail.com Wed Apr 23 17:08:38 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Apr 23 17:03:25 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1067130901.20080424005929@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <1067130901.20080424005929@gmail.com> Message-ID: > it's not refactoring! it's just adding more features - exception > handler, progress indicator, memory pool and so on. actually, code > blocks used as a sort of RAII for Haskell. are you wanna change all > those ';' when you add new variable to your C++ code? > > bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ \(archive,footer) -> do > bad_crcs <- withList $ \bad_crcs -> do > doChunks arcsize sector_size $ \bytes -> do > uiWithProgressIndicator command arcsize $ do > or > handleCtrlBreak (ignoreErrors$ fileRemove arcname_fixed) $ do > bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ \new_archive -> do > withJIT (fileOpen =<< originalURL originalName arcname) fileClose $ \original' -> do > > is just two examples from my code ... and neither of those examples would be broken by changing the associativity of $. If that kind of code had been broken, I would have complained too. So what was your point again? ;-) Cheers, /Niklas From cdsmith at twu.net Wed Apr 23 17:10:50 2008 From: cdsmith at twu.net (Chris Smith) Date: Wed Apr 23 17:05:53 2008 Subject: Meta-point: backward compatibility References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: On Wed, 23 Apr 2008 22:52:18 +0200, Niklas Broberg wrote: >> An interesting question. What is the goal of Haskell'? Is it to, like >> Python 3000, fix warts in the language in an (somewhat) incompatible >> way or is it to just standardize current practice? I think we need >> both, I just don't know which of the two Haskell' is. > > I would hope it is both. Some changes simply cannot become current > practice since they would not be compatible with existing code, and the > only place that such changes *could* be made is in a new language > version. Like you say, fail in the Monad class is one such issue that > would not be backwards compatible, and couldn't become a current > practice without some help. Chicken or egg first? I don't think I agree that fail in the Monad typeclass is a good example here, or necessarily that there is a good example. We should remember that there is a cohesive community of Haskell programmers; not a bunch of unrelated individuals who never talk to each other. It's entirely possible to spend some time recommending against using fail (as many people have been doing), and then eventually remove it. It doesn't need to break very much. This is working in our favor, so we may as well use it. IMO, this argues strongly in favor of making any backward compatible changes incrementally, instead of adopting a "Python 3000" model of postponing them and then breaking everything at once. (This is ignoring technical issues in this particular example; like what happens when a pattern match fails if there is no fail in Monad. It's entirely possible that discouraging use is the right answer in this case, and that removal need not happen. That's beside the point.) -- Chris From ndmitchell at gmail.com Wed Apr 23 17:16:52 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 23 17:11:41 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <480F72A8.2080401@gmail.com> References: <480F72A8.2080401@gmail.com> Message-ID: <404396ef0804231416n1e829eb2gc713c41a37ebf5e7@mail.gmail.com> Hi > * remove the MR entirely Finally! > * adopt Monomorphic Pattern Bindings (MPB) There are 6 reasons on that page why we shouldn't adopt MPB - of those number 5 I think is particularly compelling. There seems to be 1 main reason to remove it, which is that it has a complex translation to System F. That doesn't seem to be a particularly good reason at all! I'm guessing someone has written the translation so now applying consistently isn't that hard? Having x /= (x) is rather disturbing. Haskell has always had the attitude of doing what suits users, and making implementations work hard to handle the language features. In addition, this is a breaking change. > The nice thing about the combination of removing MR and adopting MPB is > that we retain a way to explicitly declare monomorphic bindings. These are > monomorphic bindings: > > ~x = e > x@_ = e If you really care, add a type signature. Given the tendancy for Hackage packages to have -Wall turned on and all warnings removed in patches (I'm sure half the people on Hackage have had a patch doing that from Gwern) I don't see a top-level type signature as being particularly problematic. In addition, both of those forms are non-obvious ways to declaring something monomorphic, and could easily be "cleaned up" by someone not appreciating the subtleties of sharing. Thanks Neil From dan.doel at gmail.com Wed Apr 23 17:19:21 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Apr 23 17:14:14 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1067130901.20080424005929@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <1067130901.20080424005929@gmail.com> Message-ID: <200804231719.22727.dan.doel@gmail.com> On Wednesday 23 April 2008, Bulat Ziganshin wrote: > it's not refactoring! it's just adding more features - exception > handler, progress indicator, memory pool and so on. actually, code > blocks used as a sort of RAII for Haskell. are you wanna change all > those ';' when you add new variable to your C++ code? > > bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ > \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do > doChunks arcsize sector_size $ \bytes -> do > uiWithProgressIndicator command arcsize $ do > or > handleCtrlBreak (ignoreErrors$ fileRemove arcname_fixed) $ do > bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ > \new_archive -> do withJIT (fileOpen =<< originalURL originalName arcname) > fileClose $ \original' -> do > > is just two examples from my code For what it's worth, both of these examples require no change. However, with left-associative ($), you're free to change them to (sorry for the additional lines, but my mail client breaks at 80 characters. I think they're still valid code): bracketCtrlBreak $ archiveReadFooter command arcname $ archiveClose.fst $ \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do doChunks arcsize sector_size $ \bytes -> do uiWithProgressIndicator command arcsize $ do handleCtrlBreak $ ignoreErrors (fileRemove arcname_fixed) $ do bracketCtrlBreak $ archiveCreateRW arcname_fixed $ archiveClosed $ \new_archive -> do withJIT $ fileOpen =<< originalURL originalName arcname $ fileClose $ \original' -> do Or, for a simpler example I discovered earlier, you can write: catchError $ do return 1 throwError $ strError "foo" $ \e -> return 2 Although I'm not sure how much better that is than the alternative: do return 1 throwError $ strError "foo" `catchError` \e -> return 2 -- Dan From marlowsd at gmail.com Wed Apr 23 17:21:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Apr 23 17:16:21 2008 Subject: Meta-point: backward compatibility In-Reply-To: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> Message-ID: <480FA85A.7000801@gmail.com> Johan Tibell wrote: > An interesting question. What is the goal of Haskell'? Is it to, like > Python 3000, fix warts in the language in an (somewhat) incompatible > way or is it to just standardize current practice? I think we need > both, I just don't know which of the two Haskell' is. The stated goal is still for Haskell' to be a language that is stable and relevant for large-scale development for several years to come. It is mainly a consolidation effort: that is, we aim to standardise existing practice in the form of language extensions that are currently implemented and widely used. Having said that, the standardisation process gives us the opportunity to critically assess the design of these extensions, and the design of the system as a whole, and as a result we may wish to make changes in order that the resulting language does not have inconsistencies, design flaws, or critical omissions. The language design process is also an opportunity to re-assess existing language features in the light of the wealth of experience gained over recent years. A perfect example is the monomorphism restriction: we now know that this aspect of the language really does surprise people in practice, whereas this wasn't known, or at least wasn't as clear, at the time that Haskell 98 was being designed. As for the particular question of backwards-incompatible changes, here are some criteria that Henrik Nilsson proposed early on, and I think are still relevant (i'm sure he won't mind my reposting these from the committee mailing list): * If a proposed change breaks backwards compatibility, then it is acceptable only if either - very little existing code is likely going to be broken in practice, or - + it is widely agreed that not addressing the issue really would harm the long-term relevance of Haskell', and + it is widely agreed that attempting to maintain backwards compatibility would lead to an unwieldy language design, and + the proposed design and its implications are well understood, i.e. it has been implemented in at least one system and it has been used extensively, or a strong argument can be made on the grounds of, say, an underlying well-understood theory. Libraries are another matter. We have in place mechanisms for versioning libraries and specifying precise dependencies, so changes to libraries are in a sense less fundamental than changes to the language itself. We've already stated that libraries are to be standardised separately, and I think it would also make sense for library standards to be issued more regularly than standards for the language. Cheers, Simon > > -- Johan > > On Wed, Apr 23, 2008 at 2:16 PM, Chris Smith wrote: >> There appears to be some question as to the backward compatibility goals >> of Haskell'. Perhaps it's worth bringing out into the open. >> >> >From conversations I've had and things I've read, I've always gathered >> that the main goal of Haskell' is to address the slightly embarrassing >> fact that practically no one actually writes code in Haskell, if by >> Haskell we mean the most recent completed language specification. This >> obviously argues strongly for a high degree of backward compatibility. >> >> On the other hand, I am assuming everyone agrees that we don't want to >> replicate Java, which (in my view, anyway) is rapidly becoming obsolete >> because of an eagerness to make the language complex, inconsistent, and >> generally outright flawed in order to avoid even the most unlikely of >> broken code. >> >> -- >> Chris >> >> _______________________________________________ >> 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 From ndmitchell at gmail.com Wed Apr 23 17:29:01 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 23 17:23:48 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> Hi > I think it is reasonable to look closely at the motivations for > wanting to retain the $ as is. Looking through this thread, I can find > only a single complaint raised (albeit an important one), namely > backwards compatibility. Yes, such a change would likely break quite a > few my modules. But like Cale, I would never have expected H' to be > fully backwards compatible with H98, and thus there would have to be > some way to migrate anyway. This one seems pretty simple, just let the > old Prelude be Haskell98.Prelude and import that in old code. Of > course changes that break backwards compatibility should not be made > frivolously, but I find it hard to buy having only that as an argument > for a change that otherwise seems highly reasonable. I don't want to have to do a brain mode-change between "in a Haskell98.Prelude" module and "in a Prelude" module. I don't want to copy code between modules and have it do different things. We also should remember that a large number of academic papers are written in Haskell, and unlike libraries, don't get "update releases" made. This is not a minor tweak - it will break a massive number of programs. > ps. Though to be honest I really don't see why we don't simply add > another operator instead of changing an existing one... :-) (?) anyone?* This seems a massively more sensible idea. Thanks Neil * I appreciate that a lot of non-English users might find it a bit difficult to hit this key! From cgibbard at gmail.com Wed Apr 23 17:34:36 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Apr 23 17:29:24 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> Message-ID: <89ca3d1f0804231434q5e378d7bx1e7b2c04bb2b6372@mail.gmail.com> 2008/4/23 Neil Mitchell : > We also should remember that a large number of academic papers are > written in Haskell, and unlike libraries, don't get "update releases" > made. This is not a minor tweak - it will break a massive number of > programs. How many research papers have you seen which use chained ($) applications? I can't recall a single one. - Cale From dons at galois.com Wed Apr 23 17:39:13 2008 From: dons at galois.com (Don Stewart) Date: Wed Apr 23 17:34:04 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> Message-ID: <20080423213913.GI22492@scytale.galois.com> ndmitchell: > Hi > > > I think it is reasonable to look closely at the motivations for > > wanting to retain the $ as is. Looking through this thread, I can find > > only a single complaint raised (albeit an important one), namely > > backwards compatibility. Yes, such a change would likely break quite a > > few my modules. But like Cale, I would never have expected H' to be > > fully backwards compatible with H98, and thus there would have to be > > some way to migrate anyway. This one seems pretty simple, just let the > > old Prelude be Haskell98.Prelude and import that in old code. Of > > course changes that break backwards compatibility should not be made > > frivolously, but I find it hard to buy having only that as an argument > > for a change that otherwise seems highly reasonable. > > I don't want to have to do a brain mode-change between "in a > Haskell98.Prelude" module and "in a Prelude" module. I don't want to > copy code between modules and have it do different things. > > We also should remember that a large number of academic papers are > written in Haskell, and unlike libraries, don't get "update releases" > made. This is not a minor tweak - it will break a massive number of > programs. > > > ps. Though to be honest I really don't see why we don't simply add > > another operator instead of changing an existing one... :-) > > (?) anyone?* This seems a massively more sensible idea. I'm very suspicious about the power/weight ratio of this change. Normally, for simple value-level stuff like this, provide both options: mapM / forM. =<< >>= So how about, rather than break things, just provide an alternative to ($). -- Don From ndmitchell at gmail.com Wed Apr 23 17:39:37 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 23 17:34:25 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804231434q5e378d7bx1e7b2c04bb2b6372@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> <89ca3d1f0804231434q5e378d7bx1e7b2c04bb2b6372@mail.gmail.com> Message-ID: <404396ef0804231439g2ac89083ld3206f4b738b8d22@mail.gmail.com> Hi > How many research papers have you seen which use chained ($) > applications? I can't recall a single one. You should read my papers! :-) http://www-users.cs.york.ac.uk/~ndm/downloads/paper-uniform_boilerplate_and_list_processing-30_sep_2007.pdf - section 4.1, being just the first one I picked off the pile. Haskell Workshop 2007. Thanks Neil From cgibbard at gmail.com Wed Apr 23 17:55:44 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Apr 23 17:50:33 2008 Subject: Suggestion regarding (.) and map Message-ID: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it. Additionally, add the instance: instance Functor ((->) e) where map f g x = f (g x) (and hopefully the corresponding Monad instance as well) This has the beautiful effect of unifying the notation for two of the most important things in functional programming: function composition and functorial application, and will hopefully reduce the number of extraneous functor application definitions in the Prelude and libraries. Note that the fusion law for functors: map (f . g) x = map f (map g x) When written in terms of (.) becomes: (f . g) . x = f . (g . x) which means that (.) will still be reliably associative, and that the functor in question is always easily determined by the type of the last thing in any chain of (.)'s. This has a fair level of backwards compatibility obviously, as it's strictly a generalisation on both fronts. I've been playing around with it for a while, and like it quite a lot myself, though it would be more convenient to really use if it was in the Prelude. - Cale From dan.doel at gmail.com Wed Apr 23 18:05:29 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Apr 23 18:00:21 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: Message-ID: <200804231805.29740.dan.doel@gmail.com> On Wednesday 23 April 2008, Chris Smith wrote: > I don't think I agree that fail in the Monad typeclass is a good example > here, or necessarily that there is a good example. > > We should remember that there is a cohesive community of Haskell > programmers; not a bunch of unrelated individuals who never talk to each > other. It's entirely possible to spend some time recommending against > using fail (as many people have been doing), and then eventually remove > it. It doesn't need to break very much. This is working in our favor, > so we may as well use it. IMO, this argues strongly in favor of making > any backward compatible changes incrementally, instead of adopting a > "Python 3000" model of postponing them and then breaking everything at > once. > > (This is ignoring technical issues in this particular example; like what > happens when a pattern match fails if there is no fail in Monad. It's > entirely possible that discouraging use is the right answer in this case, > and that removal need not happen. That's beside the point.) The thing is, fail isn't evil because it's intrinsically evil; it's evil because it's in the wrong place. Many monads don't have a proper notion of failure, so error just gets called, which is undesirable. (Even if they do have a proper notion of failure, it's also easy to forget to define fail appropriately, if you're defining your own monad.) Discouraging people from ever using fail, or even monadic pattern matching is also undesirable, because there are plenty of places where it is appropriate. As an example, I saw a blog post that included code like so (I don't remember the exact code, but this is comparable): f c l = length [ () | (c':'h':_) <- tails l, c == c' ] In the comments of that blog, someone had written that the code was evil, because it was an abuse of fail. But that isn't an abuse of fail (it doesn't even use fail at all, technically, since list comprehensions have their own desugaring in the report), it's appropriate use of fail. So clearly, people are already getting the wrong idea from the "don't use fail" push, and may be avoiding appropriate use of it, when it would make for clearer code. So, if you ask me, the solution isn't "discourage all use of fail." There's nothing wrong with failing in an arbitrary monad-with-failure. And we already have a class for that, called MonadPlus (or MonadZero if you split them up as in 1.4). If you move fail there, then you can encourage use of fail when appropriate. Currently, it seems difficult to do that (witness the readM thread on the libraries list, where it was proposed that fail be used (because there are multiple ways to fail), but with type restricted to MonadPlus; most people still seemed to dislike that because 'fail is evil'). -- Dan From niklas.broberg at gmail.com Wed Apr 23 18:21:26 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Wed Apr 23 18:16:14 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <20080423213913.GI22492@scytale.galois.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> <20080423213913.GI22492@scytale.galois.com> Message-ID: > I'm very suspicious about the power/weight ratio of this change. > Normally, for simple value-level stuff like this, provide both options: > > mapM / forM. =<< >>= > > So how about, rather than break things, just provide an alternative to ($). Alright, I'm not sure what the proper channel for doing this is, but I reckon here is as good as anywhere. I would like to propose that the Haskell' Prelude includes the function f $$ x = f x with the same fixity level as $ (presumably 0) but being left associative instead. And that $ is left as is. Cheers, /Niklas From s.clover at gmail.com Wed Apr 23 18:10:02 2008 From: s.clover at gmail.com (Sterling Clover) Date: Wed Apr 23 18:32:50 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: <4C294F19-7876-443A-8816-33AB3FF359A1@gmail.com> I think there are some very valid concerns about this proposal, but just to add a small datapoint -- the associativity of $ was somewhat painful and counterintuitive to me when I was first learning Haskell, and the associativity of $! doubly so. Code breakage issues aside, this seems very much the "right thing" to do. Haskell will *necessarily evolve* in a backwards-incompatible way at some point, with the move from Functional Dependencies. And meanwhile, changes to things such as the ByteString API have been taking place and causing breakage now for some time (although hopefully we've seen about the last of that). So the bigger issue seems to be -- if not Haskell', then when, precisely should a number of other issues with the core libraries be addressed, or should we let some things stay set in stone, even while other compatibility- breaking changes occur all around them? --S On Apr 23, 2008, at 4:42 PM, Niklas Broberg wrote: > When I first saw this thread, my gut response was "Aw gawds no, don't > touch my $ !!" I love $, I use it all the time, it really helps making > code more readable and more nicely structured. I would really hate for > someone to take that away from me. > > So when I came across this: > >>> This wouldn't work, you'd have to rewrite it as: >> >>> withSomeResource foo . >>> withSomeOtherThing bar . >>> yetAnotherBlockStructured thing $ ... >> >> >> it is very inconvenient - we should use either . or $ depending on >> that it's last block or not. imagine all the changes when editing >> the >> code > > ... my initial response to it was yeah, Bulat is right, that's rather > inconsistent, and it would mean a lot of changes when editing (and > it's ugly too!). > > But then I started questioning my own motives. What changes would that > be? Changing a . to a $ if I decided to remove the previous last piece > of the "pipeline"? Doesn't seem too hairy, and I have to do far worse > than that already when refactoring. Inconsistent? Doesn't it actually > make perfect sense that the actual application of the "pipeline" of > functions to some value is handled differently? Like Cale said, > wouldn't it actually be a Good Thing that we treated these things as > composition chains instead of application chains? And I could no > longer defend my own position, and so I started thinking for real. > > Refactoring doesn't become harder with this suggestion - it becomes > easier in general, just as Dan points out in #1. And I know I've been > bitten by his #2 a bunch of times, even if I haven't realized the > source of the problem until I read this thread. It's messy having to > use a lot of parenthesis just because some argument to a function > isn't the last one, and I've found myself wishing for a way to get rid > of them. I know I have at times refactored my function definitions, > switching their arguments around just to get the one that would need > the parenthesis to be the last one. > > So I dug through some of my code, picking large modules at random. As > I said I use $ *a lot*, anywhere that I can get away with it. In the > first 10 modules I looked at, I found one (1) place where I would need > to change a $ to a . to make it work. So I went to look at a bigger > module, and in what is possibly my largest self-contained module (1800 > loc including comments) I had 211 uses of $, and I would have had to > change 23 of them into . instead to make it work with a > left-associative version. All the ones where the left operand is just > a function (like return) will still work. All the ones that are > followed by a '\x -> ...' will still work. All the ones followed by a > 'do ...' will still work. On the other hand, I found 10 places where I > could immediately have gotten rid of some extra parentheses, and that > just by searching for uses of fmap in the code! > > It should be said though that changing the associativity of $ doesn't > make all code nice and clean. Consider for instance > > f (g (h x)) (k y) > > We could change that into one of > > f $ g (h x) $ k y > f (g $ h x) $ k y > > but not get rid of the parenthesis altogether, i.e. uses of $ for > different applications won't mix. But with right-associative $, the > second one would be our only option, so at least we're no worse off > than before, and perhaps it could be argued we are better off (in this > kind of situation). > > > I think it is reasonable to look closely at the motivations for > wanting to retain the $ as is. Looking through this thread, I can find > only a single complaint raised (albeit an important one), namely > backwards compatibility. Yes, such a change would likely break quite a > few my modules. But like Cale, I would never have expected H' to be > fully backwards compatible with H98, and thus there would have to be > some way to migrate anyway. This one seems pretty simple, just let the > old Prelude be Haskell98.Prelude and import that in old code. Of > course changes that break backwards compatibility should not be made > frivolously, but I find it hard to buy having only that as an argument > for a change that otherwise seems highly reasonable. > > We live in a beautiful statically typed world. If the proposed change > was such that existing code would still compile, but with a different > behavior, it would be really dangerous. That's clearly not the case > here, there's no way that code that uses $-chaining would still > compile if the associativity was changed, and any other use of $ would > still compile and work as before. The type checker is there to help > us, and it's literally a moment's work to clean up existing code to > meet these standards. (And it's even faster to import > Haskell98.Prelude if you're lazy). > > So come on, give me an argument for why $ should be right-associative > instead of complaining about broken code (that I argue won't break > even half as bad as some of you would have it). Is there really no > reason at all why right-associative is to be preferred over > left-associative? And if there is, why don't we hear it? Are you truly > arguing this because you think there's a problem with left-associative > $, or are you simply arguing because you want to stay with what you're > used to? > > "The ability to think differently today from yesterday distinguishes > the wise man from the stubborn." - John Steinbeck > > Cheers, > > /Niklas > > > ps. Though to be honest I really don't see why we don't simply add > another operator instead of changing an existing one... :-) > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime From igloo at earth.li Wed Apr 23 18:43:05 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 23 18:37:57 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> <20080423213913.GI22492@scytale.galois.com> Message-ID: <20080423224305.GA25218@matrix.chaos.earth.li> On Thu, Apr 24, 2008 at 12:21:26AM +0200, Niklas Broberg wrote: > > I'm very suspicious about the power/weight ratio of this change. > > Normally, for simple value-level stuff like this, provide both options: > > > > mapM / forM. =<< >>= > > > > So how about, rather than break things, just provide an alternative to ($). > > Alright, I'm not sure what the proper channel for doing this is, Please see http://www.haskell.org/haskellwiki/Library_submissions > f $$ x = f x Note that this clashes with Text.PrettyPrint (which doesn't necessarily mean it shouldn't be used anyway). Thanks Ian From jmccarty at sent.com Wed Apr 23 19:10:48 2008 From: jmccarty at sent.com (Jason McCarty) Date: Wed Apr 23 19:05:36 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: <20080423231048.GD873@quaternion> Niklas Broberg wrote: > ... > It should be said though that changing the associativity of $ doesn't > make all code nice and clean. Consider for instance > > f (g (h x)) (k y) > > We could change that into one of > > f $ g (h x) $ k y > f (g $ h x) $ k y > If $ is left-associative, then f (g (h x)) (k y) = (f . g . h $ x) (k y) = (f . g . h $ x) $ k y = f . g . h $ x $ k y But perhaps composing a curried function this way is unintuitive. -- Jason McCarty From john at repetae.net Wed Apr 23 19:53:14 2008 From: john at repetae.net (John Meacham) Date: Wed Apr 23 19:48:02 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <480F693B.5080509@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <1208941715.27748.153.camel@localhost> <480F693B.5080509@gmail.com> Message-ID: <20080423235314.GC17560@sliver.repetae.net> On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote: > The problem with this is that > > f !x y > > would associate differently in an expression than it does on the left hand > side of an equation, where ! is the prefix bang-pattern operator. To make > this consistent we'd have to make ! a prefix operator in expressions, or > give it the same precedence as function application; both mean a new > extension. Hmm.. that is another possible solution to the ~ ! - thing, have ~ and ! be prefix operators in general. with ~ meaning 'negate' in expressions. then parsing is the same everywhere. John -- John Meacham - ?repetae.net?john? From westondan at imageworks.com Wed Apr 23 20:11:47 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed Apr 23 20:06:34 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <20080423235314.GC17560@sliver.repetae.net> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <1208941715.27748.153.camel@localhost> <480F693B.5080509@gmail.com> <20080423235314.GC17560@sliver.repetae.net> Message-ID: <480FD043.5060705@imageworks.com> John Meacham wrote: > On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote: >> The problem with this is that >> >> f !x y >> >> would associate differently in an expression than it does on the left hand >> side of an equation, where ! is the prefix bang-pattern operator. To make >> this consistent we'd have to make ! a prefix operator in expressions, or >> give it the same precedence as function application; both mean a new >> extension. > > Hmm.. that is another possible solution to the ~ ! - thing, have ~ and ! > be prefix operators in general. with ~ meaning 'negate' in expressions. > then parsing is the same everywhere. Do prefix operators bind more or less tightly than infix operators? Either way, one of the two expressions (~2^3) or (~y$z) will parse somewhat unintuitively. I would expect these to mean ~(2^3) and (~y) $ z respectively. Dan From ganesh.sittampalam at credit-suisse.com Wed Apr 23 20:43:36 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Wed Apr 23 20:38:37 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> Aaron Denney wrote: > On 2008-04-23, Sittampalam, Ganesh wrote: > > There's plenty of code out there that doesn't have the benefit of a > > vigilant user community ready to spring into action. For example, > > Credit Suisse has several tens of thousands of lines of code written > > by internal users who are not Haskell experts, and it would be rather > > hard to explain to them that they needed to go through it all and fix > > it. > What makes them need to update to Haskell' instead of sticking with Haskell '98? (a) the fact that the code already uses several GHC extensions that will be in Haskell' and we would like to be closer to standard code (b) the expectation that at some point implementations will stop supporting H98 Is there not a general expectation when a new language standard comes out that people will migrate to it (perhaps over time)? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From cdsmith at twu.net Wed Apr 23 21:14:49 2008 From: cdsmith at twu.net (Chris Smith) Date: Wed Apr 23 21:09:51 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> Message-ID: On Thu, 24 Apr 2008 01:43:36 +0100, Sittampalam, Ganesh wrote: > Is there not a general expectation when a new language standard comes > out that > people will migrate to it (perhaps over time)? I would hope so. There's no chance that Haskell 98 would continue to be maintained with bug fixes and the like indefinitely into the future. It's a but futile, then, to suppose people can avoid Haskell' entirely for old code. -- Chris From chak at cse.unsw.edu.au Wed Apr 23 22:33:39 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Apr 23 22:28:29 2008 Subject: Meta-point: backward compatibility In-Reply-To: <480FA85A.7000801@gmail.com> References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> Message-ID: Simon Marlow: > Johan Tibell wrote: >> An interesting question. What is the goal of Haskell'? Is it to, like >> Python 3000, fix warts in the language in an (somewhat) incompatible >> way or is it to just standardize current practice? I think we need >> both, I just don't know which of the two Haskell' is. [..] > As for the particular question of backwards-incompatible changes, > here are some criteria that Henrik Nilsson proposed early on, and I > think are still relevant (i'm sure he won't mind my reposting these > from the committee mailing list): > > * If a proposed change breaks backwards compatibility, then it is > acceptable only if either > > - very little existing code is likely going to be broken in > practice, or > - + it is widely agreed that not addressing the issue really > would harm the long-term relevance of Haskell', and > + it is widely agreed that attempting to maintain backwards > compatibility would lead to an unwieldy language design, and > + the proposed design and its implications are well understood, > i.e. it has been implemented in at least one system and it has > been used extensively, or a strong argument can be made on > the grounds of, say, an underlying well-understood theory. As I have argued before on the committee list, I also think we should *not* worry about backwards incompatible changes too much in cases where a simple automatic translation from H98 to H' code is possible. Even for a large project, it is IMHO no big hardship to run a H98->H' translator over all Haskell sources. After all, this is only needed for active projects that want to make use of H'. For old code, I expect that compilers will still provide a -XHaskell98 flag or similar for the foreseeable future. As John Launchbury has said, given Haskell's current rise in popularity, anything that we do not fix with H' will be much harder, if not impossible, to fix in the future. Manuel From chak at cse.unsw.edu.au Wed Apr 23 22:54:04 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Apr 23 22:48:55 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <200804222102.36020.dan.doel@gmail.com> <480F687D.5040308@gmail.com> Message-ID: Lennart Augustsson: > I my opinion, anyone who suggest changing the associativity of $ is > insane. > Or just hating every Haskell user. Changing $ would make virtually > every Haskell program uncompilable. > > Just pick some other (Unicode?) operator, but leave $ alone. I agree that the power/weight ratio for changing the associativity of $ is not convincing at all.[1] Like the choice of (.) for function composition, it is something that Haskell will have to live with, forever. Nevertheless, I think unicode for standard operators is also a no-go for Haskell'. We discussed this on the committee list, and really, tool support for unicode is still very poor. Even cut-copy-paste of unicode text between different apps on MacOS -which seems to support unicode comparatively well- often doesn't work. Some applications, such as X11 for MacOS, don't seem to support unicode at all. The situation on Linux is even worse. Moreover, it is often difficult and definitely not uniform across platforms how to enter unicode characters. Manuel [1] Don't get me wrong, I also stumbled over the associativity of $ before and I agree that it should be different. I just don't think the gain is worth the hassle. From chak at cse.unsw.edu.au Wed Apr 23 23:13:42 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Apr 23 23:08:32 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> Message-ID: Sittampalam, Ganesh: > Aaron Denney wrote: >> On 2008-04-23, Sittampalam, Ganesh > wrote: >>> There's plenty of code out there that doesn't have the benefit of a >>> vigilant user community ready to spring into action. For example, >>> Credit Suisse has several tens of thousands of lines of code written > >>> by internal users who are not Haskell experts, and it would be > rather >>> hard to explain to them that they needed to go through it all and > fix >>> it. > >> What makes them need to update to Haskell' instead of sticking with > Haskell '98? > > (a) the fact that the code already uses several GHC extensions that > will > be in Haskell' and we would like to be closer to standard code > (b) the expectation that at some point implementations will stop > supporting > H98 Care for legacy code is important, but H' will have to break backwards compatibility in some places. And especially where you already rely on GHC extensions, you can't really expect that H' will adopt features that have been available as GHC extensions in exactly the form that they were implemented in GHC. We should be careful about where we break existing code, and we should try to support automatic translation of H98 to H' code, but any changes that we do not make now will become even more difficult in the future when there is even more Haskell code. Look at what is happening now already, industrial users applying pressure on the committee to not change the language too much for the sake of legacy code. A clear indication that anything we don't change now, we will have to live with forever. Hence, anything that is *important* to change, we should change now. We should mitigate the pain by having a H98 to H' translator and Haskell compilers will surely support a Haskell98 compatibility mode as long as there are enough users interested in such a feature. (This is not unlike the transition from K&R C to ANSI C.) Manuel From lennart at augustsson.net Thu Apr 24 03:30:04 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 24 03:24:54 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: Haskell has now reached the point where backwards compatibility is something that must be taken very seriously. The motivation behind Haskell' was to bring the most common extensions into the standard, it was all going to be done in a year. Haskell' is not a new language, but growing Haskell98 with common extension. If there's something in Haskell' that will require a change every 1000 lines, then I think it's acceptable. If there's something in Haskell' that will require changing every other line, then it's not acceptable. The existing Haskell codes bases are simply too big. So I still think changing $ is insane. Why change? If you want a new operator, make a new one. Don't make a gratuitous change that will waste countless man hours. For me it's a simple decision, if $ changes I cannot use Haskell'. :( -- Lennart On Wed, Apr 23, 2008 at 9:42 PM, Niklas Broberg wrote: > When I first saw this thread, my gut response was "Aw gawds no, don't > touch my $ !!" I love $, I use it all the time, it really helps making > code more readable and more nicely structured. I would really hate for > someone to take that away from me. > > So when I came across this: > > > > This wouldn't work, you'd have to rewrite it as: > > > > > withSomeResource foo . > > > withSomeOtherThing bar . > > > yetAnotherBlockStructured thing $ ... > > > > > > it is very inconvenient - we should use either . or $ depending on > > that it's last block or not. imagine all the changes when editing the > > code > > ... my initial response to it was yeah, Bulat is right, that's rather > inconsistent, and it would mean a lot of changes when editing (and > it's ugly too!). > > But then I started questioning my own motives. What changes would that > be? Changing a . to a $ if I decided to remove the previous last piece > of the "pipeline"? Doesn't seem too hairy, and I have to do far worse > than that already when refactoring. Inconsistent? Doesn't it actually > make perfect sense that the actual application of the "pipeline" of > functions to some value is handled differently? Like Cale said, > wouldn't it actually be a Good Thing that we treated these things as > composition chains instead of application chains? And I could no > longer defend my own position, and so I started thinking for real. > > Refactoring doesn't become harder with this suggestion - it becomes > easier in general, just as Dan points out in #1. And I know I've been > bitten by his #2 a bunch of times, even if I haven't realized the > source of the problem until I read this thread. It's messy having to > use a lot of parenthesis just because some argument to a function > isn't the last one, and I've found myself wishing for a way to get rid > of them. I know I have at times refactored my function definitions, > switching their arguments around just to get the one that would need > the parenthesis to be the last one. > > So I dug through some of my code, picking large modules at random. As > I said I use $ *a lot*, anywhere that I can get away with it. In the > first 10 modules I looked at, I found one (1) place where I would need > to change a $ to a . to make it work. So I went to look at a bigger > module, and in what is possibly my largest self-contained module (1800 > loc including comments) I had 211 uses of $, and I would have had to > change 23 of them into . instead to make it work with a > left-associative version. All the ones where the left operand is just > a function (like return) will still work. All the ones that are > followed by a '\x -> ...' will still work. All the ones followed by a > 'do ...' will still work. On the other hand, I found 10 places where I > could immediately have gotten rid of some extra parentheses, and that > just by searching for uses of fmap in the code! > > It should be said though that changing the associativity of $ doesn't > make all code nice and clean. Consider for instance > > f (g (h x)) (k y) > > We could change that into one of > > f $ g (h x) $ k y > f (g $ h x) $ k y > > but not get rid of the parenthesis altogether, i.e. uses of $ for > different applications won't mix. But with right-associative $, the > second one would be our only option, so at least we're no worse off > than before, and perhaps it could be argued we are better off (in this > kind of situation). > > > I think it is reasonable to look closely at the motivations for > wanting to retain the $ as is. Looking through this thread, I can find > only a single complaint raised (albeit an important one), namely > backwards compatibility. Yes, such a change would likely break quite a > few my modules. But like Cale, I would never have expected H' to be > fully backwards compatible with H98, and thus there would have to be > some way to migrate anyway. This one seems pretty simple, just let the > old Prelude be Haskell98.Prelude and import that in old code. Of > course changes that break backwards compatibility should not be made > frivolously, but I find it hard to buy having only that as an argument > for a change that otherwise seems highly reasonable. > > We live in a beautiful statically typed world. If the proposed change > was such that existing code would still compile, but with a different > behavior, it would be really dangerous. That's clearly not the case > here, there's no way that code that uses $-chaining would still > compile if the associativity was changed, and any other use of $ would > still compile and work as before. The type checker is there to help > us, and it's literally a moment's work to clean up existing code to > meet these standards. (And it's even faster to import > Haskell98.Prelude if you're lazy). > > So come on, give me an argument for why $ should be right-associative > instead of complaining about broken code (that I argue won't break > even half as bad as some of you would have it). Is there really no > reason at all why right-associative is to be preferred over > left-associative? And if there is, why don't we hear it? Are you truly > arguing this because you think there's a problem with left-associative > $, or are you simply arguing because you want to stay with what you're > used to? > > "The ability to think differently today from yesterday distinguishes > the wise man from the stubborn." - John Steinbeck > > Cheers, > > /Niklas > > > ps. Though to be honest I really don't see why we don't simply add > another operator instead of changing an existing one... :-) > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20080424/d60961d0/attachment.htm From ndmitchell at gmail.com Thu Apr 24 04:21:41 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Apr 24 04:16:28 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> Message-ID: <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> Hi I think Henrik's criteria are pretty close to perfect. > As I have argued before on the committee list, I also think we should *not* > worry about backwards incompatible changes too much in cases where a simple > automatic translation from H98 to H' code is possible. Even for a large > project, it is IMHO no big hardship to run a H98->H' translator over all > Haskell sources. Some questions: 1) Will I (the programmer) have to mode switch in painful ways between H98 and H'? Do I have to learn a pile of exceptions, or is there some common rule that works? (i.e. removing n+k is fine since I just don't learn it, changing the fixity of $ is not since I need to know both) 2) Will tool T (the translator) work on academic papers that have previously been published. 3) Will tool T handle all of GHC's extensions. 4) Will tool T deal with things like CPP, hsc, trhsx, happy, alex etc... - all these file formats which include embedded Haskell. 5) Will tool T ever exist. I think the answer to 2-5 is nearly certainly going to be "No". I don't think the relevance of a conversion tool should even be considered until some person steps forward and says without doubt that _they_ will write the converter. Even if they did there very best, it still won't be trivial to use in all cases. > As John Launchbury has said, given Haskell's current rise in popularity, anything that > we do not fix with H' will be much harder, if not impossible, to fix in the future. That is a very good point. Perhaps we're already a little too late. Thanks Neil From nhn at Cs.Nott.AC.UK Thu Apr 24 04:31:00 2008 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Thu Apr 24 04:28:30 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> Message-ID: <48104544.4080200@cs.nott.ac.uk> Hi all, Manuel wrote: > As I have argued before on the committee list, I also think we should > *not* worry about backwards incompatible changes too much in cases > where a simple automatic translation from H98 to H' code is possible. Yes, tools can and should help with migration, and we should keep that in mind. In particular, complicated language design to incorporate new features while maintaining backwards compatibility should be avoided where old code and new code easily can be made to work together through a compiler compatibility flag. (The discussion on records/labelled fields spring to mind.) However, I still think it is important to be conservative when it comes to breaking changes and either only consider them when the impact really would be very small, or when it is agreed it is a really important change. Even if there are tools to help with code, effort is still involved to fix the breaks, and thus it ought to be completely clear that the effort is worth it. And there is not only code: there are papers and books too! And finally, unless we're fairly strict, we'll be bogged down in a flood of discussion on gratuitous and ultimately rather superficial changes. The associativity of "$" is a case in point. So, the criteria I proposed still seem quite reasonable to me. But I'm biased, of course! :-) /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ats at offog.org Thu Apr 24 04:53:40 2008 From: ats at offog.org (Adam Sampson) Date: Thu Apr 24 04:48:29 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <20080422225339.GA27585@haskell.galois.com> (Simon Marlow's message of "Tue\, 22 Apr 2008 15\:53\:39 -0700") References: <20080422225339.GA27585@haskell.galois.com> Message-ID: Simon Marlow writes: > * add ""Make $ left associative, like application" I'm an end user of Haskell rather than an FP researcher, and I'm very strongly against this change because I don't think of $ as being function application; I think of it as the "brackets from here to the end of the expression" operator. I've always assumed that it was defined with the associativity it currently has in order to support that use. As it stands, it's one of my favourite features of Haskell. I find it particularly useful when constructing nested data structures; at the moment, it's very easy to write something like: Seq m $ Spec m var $ Only $ ProcCall m name args In that case, $ clearly has the same meaning each time. If I put something like that on a slide, I can explain the meaning of $ in a few seconds, even to an audience who aren't familiar with functional programming or Haskell. Forcing me to change the first two to . would make the code harder to write, harder to understand, and harder to explain. If people want a left-associative application operator, then it ought to be a new operator; please don't change the existing one. -- Adam Sampson From bulat.ziganshin at gmail.com Thu Apr 24 05:07:09 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Apr 24 05:05:55 2008 Subject: Meta-point: backward compatibility In-Reply-To: <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> Message-ID: <1646383677.20080424130709@gmail.com> Hello Neil, Thursday, April 24, 2008, 12:21:41 PM, you wrote: > Some questions: don't forget about most complex part: does this tool will convert human minds? :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ganesh.sittampalam at credit-suisse.com Thu Apr 24 05:27:33 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Apr 24 05:23:19 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3359@ELON17P32002A.csfb.cs-group.com> Manuel Chakravarty wrote: > Care for legacy code is important, but H' will have to break > backwards compatibility in some places. And especially where > you already rely on GHC extensions, you can't really expect > that H' will adopt features that have been available as GHC > extensions in exactly the form that they were implemented in GHC. Agreed. I was just motivating why we would want to upgrade code, not arguing that we should be able to do that with no pain at all. > We should be careful about where we break existing code, and > we should try to support automatic translation of H98 to H' code, > but any changes that we do not make now will become even more > difficult in the future when there is even more Haskell code. > Look at what is happening now already, industrial users applying > pressure on the committee to not change the language too much > for the sake of legacy code. A clear indication that anything > we don't change now, we will have to live with forever. I wasn't arguing for special treatment as an "industrial" user, just listing one datapoint that I have to counter any impression that the only or main cost to the community as a whole is fixing what's on hackage. > Hence, anything that is *important* to change, we should change now. Agreed. It's just in this case the pain of changing will be huge and the benefits marginal at best. > We should mitigate the pain by having a H98 to H' translator Such a translator would have to maintain existing layout etc, and produce reasonably nice looking code in places where it makes changes. Do we have any infrastructure that would make writing one easy? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From cdsmith at twu.net Thu Apr 24 09:24:10 2008 From: cdsmith at twu.net (Chris Smith) Date: Thu Apr 24 09:19:15 2008 Subject: Meta-point: backward compatibility References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> Message-ID: Manuel wrote: >> As John Launchbury has said, given Haskell's current rise in >> popularity, anything that we do not fix with H' will be much harder, if >> not impossible, to fix in the future. On Thu, 24 Apr 2008 09:21:41 +0100, Neil Mitchell wrote: > That is a very good point. Perhaps we're already a little too late. In general, I truly hope that this is not the case. Part of what makes Haskell such a great environment is the sense that the language values doing things right, trying out new ideas and adopting them when they work, and that the Haskell community takes pride in what we have as a language. I'm certainly willing to give up some effort fixing my old code in order to use such a language. Now, I realize that me fixing my old Haskell code means something like ten thousand lines at most, while for others it may mean a couple orders of magnitude more work; maybe it's best just to ignore me. But it would be a shame if, in the course of trying to do the right thing for Haskell's large popularity, we ended up diluting the things about the language that make it popular. So I'd argue that, in Haskell' and later on as well, it should be just a fact of life that code will occasionally break as the language evolves. If there's a consensus that something is broken, it should be fixed. If people want their code from 10 years ago to work on today's latest compiler, then there will be lots of intangible costs to achieving that goal, and I'm not sure the current spirit of Haskell will survive those costs. Unfortunately, that cost, which might be expressed as "Haskell won't be as nifty a language any more", is hard to take seriously; but I'm nevertheless convinced that it has to be taken seriously. That said, three caveats: 1. If the goal of Haskell' in particular is to codify existing practice, that's quite the admirable goal given how far behind (10 years!) things currently are in having a language standard. So this is more about how we should think about life after Haskell', rather than the current Haskell' effort. 2. Nothing I said is an argument for intentionally making people's lives painful. For example, there's no need to take approaches that break people's code between consecutive versions of Haskell with no easy way of making the code work with both. Neil said this better elsewhere, so I won't repeat it. 3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a "fix"; it's more like a change of personal taste. If I saw this as really broken, then I'd say we need to talk about how to fix it. -- Chris From simonpj at microsoft.com Thu Apr 24 10:14:47 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Apr 24 10:09:35 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5391CD7@EA-EXMSG-C334.europe.corp.microsoft.com> | Iavor: | the change is valid. I do believe that you can probably work around | the problem in many situations but the question in my mind is "why | should we have to work around stuff when we have a system that already | works?" In other words, what problem do MBPs solve? ... | Neil: | Haskell has always had the attitude of doing what suits users, and | making implementations work hard to handle the language features. In | addition, this is a breaking change. I have not made my case well! 1. [Minor point] In general I agree with what Iavor and Neil say above, but it should not be an Iron Law. If a small and easily-describable restriction in programming yields a significant simplification in implementation, that's a benefit that may be worth having. 2. More importantly, I am using System F *not* because it tells us about GHC's implementation, but because I have found that it's an excellent "litmus test" that tells when something smelly is going on. The fact that one has to go through contortions to translate pattern bindings is a Bad Sign, I believe. 3. I'm more concerned about the programmer than the implementation. Consider (f,g) = (negate, show) What type do you expect 'f' to have? A straightforward answer might be f :: (Num a, Show b) => a -> a If you don't want that, you need to explain a more complicated typing rule for pattern bindings. I'll ask the same about (f,g) = (reverse, length) A simple and consistent story is that all the pattern bound variables are generalised over all the class constraints and all the type variables of the RHS. But I bet that is not what you want. 4. Would it make a difference if you gave a type signature for f? Can f,g have different sets of class constraints? (H98 says 'no' for class constraints, but 'yes' for type variables, which is an obvious wart). 5. I'm also concerned about the interaction with strictness. let (f,g) = e in f (...f...g...) Here 'f' is clearly used strictly, so the pair will certainly be evaluated. Does this mean the same? case e of (f,g) -> f (...f..g...) 6. If we allow bang patterns, what does !(f,g) = e actually mean? The implementation is not the driving force. It's just the way I know that something is afoot. What is the problem MPB tries to solve? The problem of specifying the type system for pattern bindings. Try writing down the full typing rules for pattern bindings, including type signatures! Higher-rank types too. Simon From apfelmus at quantentunnel.de Thu Apr 24 13:10:47 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Apr 24 13:05:44 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> Message-ID: Chris Smith wrote: > I'm definitely not arguing for this ($) > associativity change, for example, and my objection is the backward > compatibility. But ultimately, it's more like a combination of > incompatibility and the lack of a really compelling story on why it > should be one way or the other. I have a hard time calling this a "fix"; > it's more like a change of personal taste. The $ problem is an interesting one, for it has the following properties: 1) Someone who learns Haskell for the first time will not complain about either associativity. Whether it's left or right associative is rather unimportant, it is how it is and either way is fine. 2) But once the decision has been made, it's nigh impossible to change it, simply because everybody has relied on one particular associativity of $ all the time. 3) Assuming that this associativity is a matter of taste, it only sounds fair to experiment and try different tastes. So, Cale has a Prelude with left associative $ and Lennart has a different personal Prelude as well and I'm going too taste a sip of either one and brew my own functional coffee. But in that situation, the defining property of a standard, namely that everybody uses the same $ , is gone, everybody would have to check which one is used in which module. It's like being forced to eat chicken only because chicken lay eggs. Some may like it, some may not, but the eggs will hatch new chicken who lay new eggs for all eternity :) Regards, apfelmus From sah at awesame.org Thu Apr 24 13:11:04 2008 From: sah at awesame.org (Steven Hazel) Date: Thu Apr 24 13:05:51 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> Message-ID: <9c51cbd60804241011o1c571f87q52e475e07c9bfcbf@mail.gmail.com> On Wed, Apr 23, 2008 at 8:13 PM, Manuel M T Chakravarty wrote: > We should be careful about where we break existing code, and we should try to support automatic translation of H98 to H' code, but any changes that we do not make now will become even more difficult in the future when there is even more Haskell code. Look at what is happening now already, industrial users applying pressure on the committee to not change the language too much for the sake of legacy code. A clear indication that anything we don't change now, we will have to live with forever. > > Hence, anything that is *important* to change, we should change now. We should mitigate the pain by having a H98 to H' translator and Haskell compilers will surely support a Haskell98 compatibility mode as long as there are enough users interested in such a feature. (This is not unlike the transition from K&R C to ANSI C.) For ($), automatic translation could be as simple as changing a couple module imports: import Prelude hiding (($)) import Haskell98 (($)) -- Steven Hazel sah@awesame.org From marlowsd at gmail.com Thu Apr 24 13:12:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Apr 24 13:07:26 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> Message-ID: <4810BF7B.8060809@gmail.com> Iavor Diatchki wrote: > I should also point out that if we were to adopt the MBP rule, we > would have to adjust the definition of what pattern bindings mean. > For example, I think that this is how things are desugared at the > moment: > (x,y) = e > becomes > new_var = e > x = case new_var of (v,_) -> v > y = case new_var of (_,v) -> v The report doesn't actually mention this translation although it is widely used to implement pattern bindings, and in some compilers (not GHC) the translation is done before type checking. What's interesting to me is that perhaps this gives us a way to understand what the static semantics of pattern bindings should be, absent MPB. e.g. (x,y) = (negate,show) (Simon's example) translates to z = (negate,show) x = fst z y = snd z and we can see why both x and y end up generalised over both constraints, because z :: (Num a, Show b) => (a -> a, b -> String) and this also explains why the pattern-bound variables don't have to be generalised over all the type variables. e.g. in z = (id,id) x = fst z y = snd z we'd get z :: forall a b . (a->a, b->b) x :: forall a . a -> a not x :: forall a b . a -> a because the generalisation step for x only generalises over the type variables in the type arising from its right-hand side. Cheers, Simon > It seems that under MBP the second program is not equivalent to the > first because it is more polymorphic. > > -Iavor > > > > On Wed, Apr 23, 2008 at 10:32 AM, Simon Marlow wrote: >> Folks, >> >> The current proposal on the table for what to do about the monomorphism >> restriction (henceforth MR) is >> >> * remove the MR entirely >> * adopt Monomorphic Pattern Bindings (MPB) >> >> Right now, the committee is almost uniformly in favour of dropping the MR, >> and most of us are coming round to the idea of MPB. Since this area has >> historically been difficult to achieve a concensus on, I'm excited that we >> appear to be close to making a decision, and a good one at that! >> >> The arguments for removing the MR are pretty well summarised on the wiki: >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphismRestriction >> >> You can read about MPB here: >> >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings >> >> GHC has implemented MPB by default (i.e. we deviate slightly from Haskell >> 98) since 6.8.1. >> >> The nice thing about the combination of removing MR and adopting MPB is >> that we retain a way to explicitly declare monomorphic bindings. These are >> monomorphic bindings: >> >> ~x = e >> x@_ = e >> >> or if you don't mind a strict binding: !x = e. The wiki points out that >> >> (x) = e >> >> would also be monomorphic, but arguably this is in poor taste since we >> expect (x) to mean the same as x everywhere. >> >> Cheers, >> Simon >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> From g9ks157k at acme.softbase.org Thu Apr 24 13:46:17 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 13:41:29 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <78A3C5650E28124399107F21A1FA41945B3315@ELON17P32002A.csfb.cs-group.com> References: <20080415181344.GA29673@haskell.galois.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <78A3C5650E28124399107F21A1FA41945B3315@ELON17P32002A.csfb.cs-group.com> Message-ID: <200804241946.17402.g9ks157k@acme.softbase.org> Am Freitag, 18. April 2008 11:54 schrieb Sittampalam, Ganesh: > Simon Peyton Jones wrote: > > Not allowing infix functions on the LHS would be a notable simplification. > > This would significantly weaken a useful property of Haskell, that > definitions and uses often share the same concrete syntax. It's very natural > to be able to define things that way and it would be a real shame to lose it > (and I think it would break a lot of existing code). +1 (f . g) x = f (g x) is really nice. > > In any case, I've always thought this was weird: > > Just x == Just y = x == y > > It takes a little getting used to, but I don't find it that weird. +1 > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 13:51:07 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 13:45:55 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <20080421235818.GT17560@sliver.repetae.net> References: <20080415181344.GA29673@haskell.galois.com> <480CFAD1.7070205@gmail.com> <20080421235818.GT17560@sliver.repetae.net> Message-ID: <200804241951.07458.g9ks157k@acme.softbase.org> Am Dienstag, 22. April 2008 01:58 schrieb John Meacham: > [?] > There is also the proposal to change the fixity of '$'. Why should the fixity of $ being changed? I thought, the reason for $ was that you can write a $ b $ c. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 14:45:40 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 14:40:38 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <200804242045.40806.g9ks157k@acme.softbase.org> Am Dienstag, 22. April 2008 09:33 schrieb Simon Peyton-Jones: > [?] > One reason I've failed to do so is because I have not come under enough > pressure! If I thought there were dozens of people slavering at the chops > for class aliases, that would put it more firmly on my radar. I would really, really like to see class aliases (or something similar) in GHC! For example, I?m currently writing lecture notes for a functional programming lecture. During this process I had to see again how unattractive it is that Functor and Applicative aren?t superclasses of Monad. You have to teach your students some historical background in order to make sense of this fact. Even if Functor would have been made a Monad superclass in Haskell 98, the post-98 introduction of Applicative would have prevented it from being a superclass of Monad. I think, we should have the possibility to refine class hierarchies later. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 14:48:15 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 14:42:59 2008 Subject: Haskell' - class aliases In-Reply-To: <20080423041823.GX17560@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> Message-ID: <200804242048.15740.g9ks157k@acme.softbase.org> Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham: > On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: > > Is this the most up-to-date description of the proposal? > > http://repetae.net/recent/out/classalias.html > > There were a few changes proposed in the discussion that followed my > announcement that I wanted to make. The one I can remember now is > getting rid of the 'alias' keyword since the equals sign unabiguously > identifies it as an alias. I will dig through the archive to find the > others.. I also have some remark: Why not write > class Eq a => Num a = (Additive a, Multiplicative a) instead of > class Num a = Eq a => (Additive a, Multiplicative a) The former would better match the syntax for ordinary class declarations like: > class Eq a => Num a where > > [?] > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 14:51:12 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 14:45:56 2008 Subject: Haskell' - class aliases In-Reply-To: <20080423041823.GX17560@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> Message-ID: <200804242051.13075.g9ks157k@acme.softbase.org> Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham: > On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: > > Is this the most up-to-date description of the proposal? > > http://repetae.net/recent/out/classalias.html > > There were a few changes proposed in the discussion that followed my > announcement that I wanted to make. The one I can remember now is > getting rid of the 'alias' keyword since the equals sign unabiguously > identifies it as an alias. I will dig through the archive to find the > others.. > > > I've just had another look, which threw up quite a few questions in my > > mind. I wonder what would be a good list to discuss it. Maybe this > > one is not bad, because it has people interested in Haskell > > innovation, regardless of whether it's a live Haskell' candidate? > > Sounds good to me. > > John By the way, what are your current thoughts about your supertyping proposal. At least, on you say: > This functionality becomes even more necessary when faced with binary-only > libraries and standard language features which cannot be easily rewritten or > overridden without great effort. This seems to be an advantage compared to the class alias library. On the other hand, it looks a bit weird to me that you can express a class relation in two different ways: A t => B t and B t <= A t. Best wishes, Wolfgang From cgibbard at gmail.com Thu Apr 24 14:55:02 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Apr 24 14:49:55 2008 Subject: patch applied (haskell-prime-status): BangPatterns: probably accept ==> undecided In-Reply-To: <200804241951.07458.g9ks157k@acme.softbase.org> References: <20080415181344.GA29673@haskell.galois.com> <480CFAD1.7070205@gmail.com> <20080421235818.GT17560@sliver.repetae.net> <200804241951.07458.g9ks157k@acme.softbase.org> Message-ID: <89ca3d1f0804241155r632cb275lcbba96d522abb365@mail.gmail.com> 2008/4/24 Wolfgang Jeltsch : > Am Dienstag, 22. April 2008 01:58 schrieb John Meacham: > Why should the fixity of $ being changed? I thought, the reason for $ was > that you can write a $ b $ c. Well, the reasons for this were discussed on another thread recently, but in brief, you can always rewrite "f $ g $ h $ x" as "f . g . h $ x", whereas there's no way to remove the parentheses from expressions like "f (g x) (h y) (k z)", which, if ($) were left associative like function application normally is, could be written "f $ g x $ h y $ k z". Moreover, using function composition in place of ($) where possible should probably be considered better style regardless, as expressions written that way effectively have more subexpressions, because (.) is an associative operator. For instance, in "f $ g $ h $ x", the substring "g $ h" is meaningless, but in "f . g . h $ x", we have that "g . h" is a well-typed function, as well as "f . g". Another good reason is that we certainly wouldn't want ($!) to have a different associativity than ($), and the left-associative form of ($!) is far more useful than the present right-associative one. Strictly applying a function to any parameter but the last currently requires awkward parentheses. In combination with left-associating ($), a left-associating ($!) will allow any combination of strict applications to be easily expressed. I tend to think of the present associativity of ($) as a kind of oversight which people started to abuse in place of proper function composition, whereas the alternate associativity has real benefits over this one. - Cale From g9ks157k at acme.softbase.org Thu Apr 24 15:00:24 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 14:55:13 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1208906440.27748.139.camel@localhost> References: <20080422225339.GA27585@haskell.galois.com> <1208906440.27748.139.camel@localhost> Message-ID: <200804242100.24733.g9ks157k@acme.softbase.org> Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts: > [?] > Surely there was a justification to having $ be the opposite > associativity from application and not just a different precedence. Does > anyone know what it was? Probably the fact that you can write > f $ g $ h $ u $ v $ w $ x instead of > f (g (h (u (v (w x))))) and thereby avoid building forests of parantheses. > Duncan Best wishes, Wolfgang From cgibbard at gmail.com Thu Apr 24 15:09:20 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Apr 24 15:04:06 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804242100.24733.g9ks157k@acme.softbase.org> References: <20080422225339.GA27585@haskell.galois.com> <1208906440.27748.139.camel@localhost> <200804242100.24733.g9ks157k@acme.softbase.org> Message-ID: <89ca3d1f0804241209ia236db2o5c90bfb8c581866d@mail.gmail.com> 2008/4/24 Wolfgang Jeltsch : > Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts: > > [?] > > > > Surely there was a justification to having $ be the opposite > > associativity from application and not just a different precedence. Does > > anyone know what it was? > > Probably the fact that you can write > > > f $ g $ h $ u $ v $ w $ x > > instead of > > > f (g (h (u (v (w x))))) > > and thereby avoid building forests of parantheses. > But of course, f . g . h . u . v . w $ x means the same thing, and has nicer properties with regard to refactoring and formal reasoning due to the associativity of (.), so probably not a whole lot of thought went into the choice. - Cale From g9ks157k at acme.softbase.org Thu Apr 24 15:17:34 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 15:12:22 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <1765841915.20080423115824@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <89ca3d1f0804230026o3b836b89w96696cf5a8116f5f@mail.gmail.com> <1765841915.20080423115824@gmail.com> Message-ID: <200804242117.34819.g9ks157k@acme.softbase.org> Am Mittwoch, 23. April 2008 09:58 schrieb Bulat Ziganshin: > [?] > my main point is that considering space-less operators as having > larger priority is our natural habit. Really??? I?ve never heard of people using spaceless operators for stating precedence before. And it contradicts nice typesetting. In my opinion, an operator needs space around it, otherwise it looks ugly. And I don?t want to have lhs2TeX-typeset source code where infix operators sometimes have the nice TeX spacing and sometimes are not surrounded by spaces at all. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 15:19:57 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 15:14:47 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> Message-ID: <200804242119.57894.g9ks157k@acme.softbase.org> Am Mittwoch, 23. April 2008 10:06 schrieb Cale Gibbard: > [?] > I believe that migrating code will be quite a task regardless of the > outcome here, but at least for the packages that are in Hackage, the > system helpfully reports build failures, so we'll know where the > breakages are, and roughly what's left to be done. Why not writing a tool which replaces all occurences of a $ b $ c $ d by a . b . c $ d? > - Cale Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 15:27:31 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 15:22:15 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> Message-ID: <200804242127.31837.g9ks157k@acme.softbase.org> 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. 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. > [?] > Manuel Best wishes, Wolfgang From john at repetae.net Thu Apr 24 15:27:51 2008 From: john at repetae.net (John Meacham) Date: Thu Apr 24 15:22:35 2008 Subject: Haskell' - class aliases In-Reply-To: <200804242048.15740.g9ks157k@acme.softbase.org> References: <480CD7BB.2040601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <200804242048.15740.g9ks157k@acme.softbase.org> Message-ID: <20080424192750.GE17560@sliver.repetae.net> On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote: > Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham: > > On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: > > > Is this the most up-to-date description of the proposal? > > > http://repetae.net/recent/out/classalias.html > > > > There were a few changes proposed in the discussion that followed my > > announcement that I wanted to make. The one I can remember now is > > getting rid of the 'alias' keyword since the equals sign unabiguously > > identifies it as an alias. I will dig through the archive to find the > > others.. > > I also have some remark: Why not write > > > class Eq a => Num a = (Additive a, Multiplicative a) > > instead of > > > class Num a = Eq a => (Additive a, Multiplicative a) Well, because you can think of 'Num a' as an alias for 'Eq a => (Additive a, Multiplicative a)', not that Eq is a superclass of Num which the class declaration syntax implies. John -- John Meacham - ?repetae.net?john? From g9ks157k at acme.softbase.org Thu Apr 24 15:38:22 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 15:33:05 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <20080423224305.GA25218@matrix.chaos.earth.li> References: <20080422225339.GA27585@haskell.galois.com> <20080423224305.GA25218@matrix.chaos.earth.li> Message-ID: <200804242138.22307.g9ks157k@acme.softbase.org> Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh: > [?] > Please see > http://www.haskell.org/haskellwiki/Library_submissions > > > f $$ x = f x > > Note that this clashes with Text.PrettyPrint I also doesn?t correspond to $!. We should introduce $$! then. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Apr 24 15:41:00 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 15:35:44 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> Message-ID: <200804242141.00757.g9ks157k@acme.softbase.org> Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson: > Haskell has now reached the point where backwards compatibility is something > that must be taken very seriously. Would you be opposed to a Haskell 2 which would break lots of things? > [?] Best wishes, Wolfgang From john at repetae.net Thu Apr 24 15:44:32 2008 From: john at repetae.net (John Meacham) Date: Thu Apr 24 15:39:16 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804242138.22307.g9ks157k@acme.softbase.org> References: <20080422225339.GA27585@haskell.galois.com> <20080423224305.GA25218@matrix.chaos.earth.li> <200804242138.22307.g9ks157k@acme.softbase.org> Message-ID: <20080424194431.GF17560@sliver.repetae.net> On Thu, Apr 24, 2008 at 09:38:22PM +0200, Wolfgang Jeltsch wrote: > Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh: > > [?] > > > Please see > > http://www.haskell.org/haskellwiki/Library_submissions > > > > > f $$ x = f x > > > > Note that this clashes with Text.PrettyPrint > > I also doesn?t correspond to $!. We should introduce $$! then. I don't think either of these are necessary and eat up valuable operator-space. John -- John Meacham - ?repetae.net?john? From johan.tibell at gmail.com Thu Apr 24 15:51:46 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Apr 24 15:46:33 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804242141.00757.g9ks157k@acme.softbase.org> References: <20080422225339.GA27585@haskell.galois.com> <200804242141.00757.g9ks157k@acme.softbase.org> Message-ID: <90889fe70804241251x282bb964r243e59d0edbe680f@mail.gmail.com> On Thu, Apr 24, 2008 at 3:41 PM, Wolfgang Jeltsch wrote: > Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson: > > > Haskell has now reached the point where backwards compatibility is something > > that must be taken very seriously. > > Would you be opposed to a Haskell 2 which would break lots of things? I would! No new language standard should break lots of things! It could break some things and should provide easy rewrite rules for code (or better yet a tool like Python's 2to3) to move from standard A to standard B for most of the things that break. From g9ks157k at acme.softbase.org Thu Apr 24 16:15:45 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 16:10:45 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> Message-ID: <200804242215.45672.g9ks157k@acme.softbase.org> Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard: > [?] > Rename fmap to map This would be really great! There is no point in having a map just for lists and a general map for functors since the list map is the same as the list instance?s functor map. And identifiers with a single lowercase letter in front or after a lowercase word (fmap, foldr, etc.) are not nice, in my opinion. > (like it was in Haskell 1.4), It really was this way in Haskell 1.4? Why was it changed? > and define (.) as a synonym for it. I don?t think that this is reasonable. (.) corresponds to the little circle in math which is a composition. So (.) = (<<<) would be far better. > Additionally, add the instance: > > instance Functor ((->) e) where > map f g x = f (g x) > > (and hopefully the corresponding Monad instance as well) And hopefully the corresponding Applicative instance as well! Applicative functors are a very nice thing. (So a big ?thank you? to Conor and Ross.) > [?] Best wishes, Wolfgang From wnoise at ofb.net Thu Apr 24 16:18:10 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Apr 24 16:13:09 2008 Subject: Meta-point: backward compatibility References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> Message-ID: On 2008-04-23, Simon Marlow wrote: > Johan Tibell wrote: >> An interesting question. What is the goal of Haskell'? Is it to, like >> Python 3000, fix warts in the language in an (somewhat) incompatible >> way or is it to just standardize current practice? I think we need >> both, I just don't know which of the two Haskell' is. > > The stated goal is still for Haskell' to be a language that is stable > and relevant for large-scale development for several years to come. > > It is mainly a consolidation effort: that is, we aim to standardise > existing practice in the form of language extensions that are currently > implemented and widely used. Having said that, the standardisation > process gives us the opportunity to critically assess the design of > these extensions, and the design of the system as a whole, and as a > result we may wish to make changes in order that the resulting language > does not have inconsistencies, design flaws, or critical omissions. Given a fairly limited goal of "consolidating current practice", not much should change. And this is a very useful thing to do. The problem is that many of us don't see any opportunity for large change after this. We expect any changes in the hypothetical Haskell 2 (or 201x) to be resisted tooth and nail by the larger crowd as Haskell grows. And there is a lot that clearly isn't battle tested in a reasonable new form, though the current practice is widely agreed upon to be broken. Examples include all monads having fail, rather than only those in a subclass, monad not being a subclass of functor, and the whole numeric hierarchy issue (which I don't think can be properly designed unless we know whether it's going to be FDs or ATs, though, of course, designing it for either would provide valuable experience for the limitations of both), Many of these are "mere" library changes, but library changes that are nearly as fundamental as language changes, because of how tied in the prelude is currently. It's still not entirely straightforward to replace the prelude with a custom one, which makes it harder to test some of these changes in real world use. All of these factors combine to make the ones who get annoyed with these problems to want to shoehorn in changes right now. -- Aaron Denney -><- From g9ks157k at acme.softbase.org Thu Apr 24 16:21:03 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Apr 24 16:15:48 2008 Subject: Haskell' - class aliases In-Reply-To: <20080424192750.GE17560@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <200804242048.15740.g9ks157k@acme.softbase.org> <20080424192750.GE17560@sliver.repetae.net> Message-ID: <200804242221.03492.g9ks157k@acme.softbase.org> Am Donnerstag, 24. April 2008 21:27 schrieb John Meacham: > On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote: > [?] > > I also have some remark: Why not write > > > > > class Eq a => Num a = (Additive a, Multiplicative a) > > > > instead of > > > > > class Num a = Eq a => (Additive a, Multiplicative a) > > Well, because you can think of 'Num a' as an alias for 'Eq a => > (Additive a, Multiplicative a)', not that Eq is a superclass of Num > which the class declaration syntax implies. Hmm, in what way is Num a an alias for Eq a => (Additive a, Multiplicative a)? You cannot write this: > square :: (Eq a => (Additive a, Multiplicative a)) => a -> a I would say: ?Under the condition that Eq a holds, Num a is an alias for (Additive a, Multiplicative a). And this seems to be perfectly expressed by my above proposal. Best wishes, Wolfgang From cgibbard at gmail.com Thu Apr 24 16:42:44 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Apr 24 16:37:35 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <200804242215.45672.g9ks157k@acme.softbase.org> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <200804242215.45672.g9ks157k@acme.softbase.org> Message-ID: <89ca3d1f0804241342j913648dsc3101f2b8dfcbdc1@mail.gmail.com> 2008/4/24 Wolfgang Jeltsch : > Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard: > > [?] > > > Rename fmap to map > > This would be really great! There is no point in having a map just for lists > and a general map for functors since the list map is the same as the list > instance's functor map. And identifiers with a single lowercase letter in > front or after a lowercase word (fmap, foldr, etc.) are not nice, in my > opinion. > > > > (like it was in Haskell 1.4), > > It really was this way in Haskell 1.4? Why was it changed? > > > > and define (.) as a synonym for it. > > I don't think that this is reasonable. (.) corresponds to the little circle > in math which is a composition. So (.) = (<<<) would be far better. > But the realisation here is that composition *is* functor application, for a certain rather important functor. :) - Cale From cgibbard at gmail.com Thu Apr 24 16:55:53 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Apr 24 16:50:39 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> Message-ID: <89ca3d1f0804241355y77664d0dp6fe02e27d8fe7217@mail.gmail.com> 2008/4/24 Chris Smith : > 3. Don't get me wrong; I'm definitely not arguing for this ($) > associativity change, for example, and my objection is the backward > compatibility. But ultimately, it's more like a combination of > incompatibility and the lack of a really compelling story on why it > should be one way or the other. I have a hard time calling this a "fix"; > it's more like a change of personal taste. If I saw this as really > broken, then I'd say we need to talk about how to fix it. How about the argument that the right associative ($), in conjuction with (.) is less expressive than that left associative one in conjunction with (.)? That is, more parentheses can be avoided. Everything you can do with chained right associative ($), you can do with (.) and a single ($), whereas there are things you can express with chained left-associative ($) which you need parentheses to express without it. - Cale From dan.doel at gmail.com Thu Apr 24 17:20:22 2008 From: dan.doel at gmail.com (Dan Doel) Date: Thu Apr 24 17:15:13 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <200804242215.45672.g9ks157k@acme.softbase.org> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <200804242215.45672.g9ks157k@acme.softbase.org> Message-ID: <200804241720.22702.dan.doel@gmail.com> On Thursday 24 April 2008, Wolfgang Jeltsch wrote: > I don?t think that this is reasonable. (.) corresponds to the little > circle in math which is a composition. So (.) = (<<<) would be far better. Were I building a library, this might be the direction I'd take things. They're two incompatible generalizations, and you have to decide which is more important to you. For instance, you can generalize from arrows into categories (with objects in *): class Category (~>) where id :: a ~> a (.) :: (b ~> c) -> (a ~> b) -> (a ~> c) And, of course, from this, you get the usual meanings for (->): instance Category (->) where id x = x (f . g) x = f (g x) An example of a Category that isn't an Arrow (I think) is: newtype Op (~>) a b = Op { unOp :: b ~> a } instance Category (~>) => Category (Op (~>)) where id = Op id -- (.) :: (b <~ c) -> (a <~ b) -> (a <~ c) (Op f) . (Op g) = Op (g . f) type HaskOp = Op (->) (Why is this even potentially useful? Well, if you define functors with reference to what two categories they relate, you get (pardon the illegal syntax): map :: (a ~1> b) -> (f a ~2> f b) Which gives you current covariant endofunctors if (~1>) = (~2>) = (->), but it also gives you contravariant endofunctors if (~1>) = (->) and (~2>) = Op (->). Is this a useful way of structuring things in practice? I don't know.) Now, going the (.) = map route, one should note the following Functor instance: instance (Arrow (~>)) => Functor ((~>) e) where -- fmap :: (a -> b) -> (e ~> a) -> (e ~> b) fmap f g = arr f <<< g So, in this case (.) is composition of a pure function with an arrow, but it does not recover full arrow composition. It certainly doesn't recover composition in the general Category class above, because there's no operation for lifting functions into an arbitrary Category (think Op: given a function (a -> b), I can't get a (b -> a) in general). (At a glance, if you have the generalized Functors that reference their associated Categories, you have: map (a ~1> b) -> (e ~3> a) ~2> (e ~3> b) so for (~1>) = (~3>), and (~2>) = (->), you've recovered (.) for arbitrary categories: instance (Category (~>) => Functor ((~>) e) (~>) (->) where map f g = f . g so, perhaps with a generalized Functor, you can have (.) = map *and* have (.) be a generalized composition.) Now, the above Category stuff isn't even in any library that I know of, would break tons of stuff (with the generalized Functor, which is also kind of messy), and I haven't even seriously explored it, so it'd be ridiculous to request going in that direction for H'. But, restricted to the current libraries, if you do want to generalize (.), you have to decide whether you want to generalize it as composition of arrows, or as functor application. The former isn't a special case of the latter (with the current Functor, at least). Generalizing (.) to Arrow composition seems more natural to me, but generalizing to map may well have more uses. -- Dan From lennart at augustsson.net Thu Apr 24 17:24:59 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Apr 24 17:19:44 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804242141.00757.g9ks157k@acme.softbase.org> References: <20080422225339.GA27585@haskell.galois.com> <200804242141.00757.g9ks157k@acme.softbase.org> Message-ID: Haskell 2 (whatever it is), does not have the goals that were stated for Haskell', so I can accept disruptive changes. Haskell' has (had?) some very clear goals, and breaking every existing program was not one of them. On Thu, Apr 24, 2008 at 8:41 PM, Wolfgang Jeltsch < g9ks157k@acme.softbase.org> wrote: > Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson: > > Haskell has now reached the point where backwards compatibility is > something > > that must be taken very seriously. > > Would you be opposed to a Haskell 2 which would break lots of things? > > > [?] > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20080424/03585eb6/attachment.htm From cgibbard at gmail.com Thu Apr 24 17:31:09 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Apr 24 17:25:56 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <200804241720.22702.dan.doel@gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <200804242215.45672.g9ks157k@acme.softbase.org> <200804241720.22702.dan.doel@gmail.com> Message-ID: <89ca3d1f0804241431j5a8e1894sa1671b997846323e@mail.gmail.com> 2008/4/24 Dan Doel : > On Thursday 24 April 2008, Wolfgang Jeltsch wrote: > > I don't think that this is reasonable. (.) corresponds to the little > > circle in math which is a composition. So (.) = (<<<) would be far better. > > Were I building a library, this might be the direction I'd take things. > They're two incompatible generalizations, and you have to decide which is > more important to you. > > For instance, you can generalize from arrows into categories (with objects in > *): > > class Category (~>) where > id :: a ~> a > (.) :: (b ~> c) -> (a ~> b) -> (a ~> c) > > And, of course, from this, you get the usual meanings for (->): > > instance Category (->) where > id x = x > (f . g) x = f (g x) > > An example of a Category that isn't an Arrow (I think) is: > > newtype Op (~>) a b = Op { unOp :: b ~> a } > > instance Category (~>) => Category (Op (~>)) where > id = Op id > -- (.) :: (b <~ c) -> (a <~ b) -> (a <~ c) > (Op f) . (Op g) = Op (g . f) > > type HaskOp = Op (->) > > (Why is this even potentially useful? Well, if you define functors with > reference to what two categories they relate, you get (pardon the illegal > syntax): > > map :: (a ~1> b) -> (f a ~2> f b) > > Which gives you current covariant endofunctors if (~1>) = (~2>) = (->), but it > also gives you contravariant endofunctors if (~1>) = (->) and (~2>) = Op > (->). Is this a useful way of structuring things in practice? I don't know.) > > Now, going the (.) = map route, one should note the following Functor > instance: > > instance (Arrow (~>)) => Functor ((~>) e) where > -- fmap :: (a -> b) -> (e ~> a) -> (e ~> b) > fmap f g = arr f <<< g > > So, in this case (.) is composition of a pure function with an arrow, but it > does not recover full arrow composition. It certainly doesn't recover > composition in the general Category class above, because there's no operation > for lifting functions into an arbitrary Category (think Op: given a function > (a -> b), I can't get a (b -> a) in general). > > (At a glance, if you have the generalized Functors that reference their > associated Categories, you have: > > map (a ~1> b) -> (e ~3> a) ~2> (e ~3> b) > > so for (~1>) = (~3>), and (~2>) = (->), you've recovered (.) for arbitrary > categories: > > instance (Category (~>) => Functor ((~>) e) (~>) (->) where > map f g = f . g > > so, perhaps with a generalized Functor, you can have (.) = map *and* have (.) > be a generalized composition.) > > Now, the above Category stuff isn't even in any library that I know of, would > break tons of stuff (with the generalized Functor, which is also kind of > messy), and I haven't even seriously explored it, so it'd be ridiculous to > request going in that direction for H'. But, restricted to the current > libraries, if you do want to generalize (.), you have to decide whether you > want to generalize it as composition of arrows, or as functor application. > The former isn't a special case of the latter (with the current Functor, at > least). > > Generalizing (.) to Arrow composition seems more natural to me, but > generalizing to map may well have more uses. > > -- Dan Right, my own preference in this regard is to generalise in the direction that (<<<) would be a method of Category, which is a generalisation of Arrow. We currently at least have way more Functor instances than Category instances, so it seems sensible to pick the shorter notation for the more common case, but I do strongly think we should start pushing things in this direction. These are all really nice, extremely general ideas which can make libraries nicely uniform. - Cale From twanvl at gmail.com Thu Apr 24 18:06:58 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Thu Apr 24 18:01:35 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> Message-ID: <48110482.8070803@gmail.com> Cale Gibbard wrote: > Hello, > > In keeping with my small but seemingly extremely controversial > suggestions for changes to the Prelude, here's a suggestion which I > think is elegant and worth considering for the Haskell' Prelude: > > Rename fmap to map (like it was in Haskell 1.4), and define (.) as a > synonym for it. One thing I fear (though that fear may be irrational) is that you get code that looks like "(.) . ((.) . (.) .)". To me, and I expect to many people, map and composition are different things, and used in different ways. If both are written as a dot it will take extra mental effort to decipher the meaning of a program. The potential for writing code that resembles the worst outputs of the @pl lambdabot plugin also becomes larger. Cale: do you have some real world examples of code you wrote using (.) = fmap? Secondly, I am really fond of the Applicative notation <$>, which goes great together with <*>. A lighter notation would be nice, but I see no good way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?) Twan From cgibbard at gmail.com Thu Apr 24 18:25:39 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Apr 24 18:20:24 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <48110482.8070803@gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <48110482.8070803@gmail.com> Message-ID: <89ca3d1f0804241525ha44a499j2c5fd8bbe83f8d81@mail.gmail.com> 2008/4/24 Twan van Laarhoven : > Cale Gibbard wrote: > > > > Hello, > > > > In keeping with my small but seemingly extremely controversial > > suggestions for changes to the Prelude, here's a suggestion which I > > think is elegant and worth considering for the Haskell' Prelude: > > > > Rename fmap to map (like it was in Haskell 1.4), and define (.) as a > > synonym for it. > > > > One thing I fear (though that fear may be irrational) is that you get code > that looks like "(.) . ((.) . (.) .)". To me, and I expect to many people, > map and composition are different things, and used in different ways. If > both are written as a dot it will take extra mental effort to decipher the > meaning of a program. The potential for writing code that resembles the > worst outputs of the @pl lambdabot plugin also becomes larger. This is why I recommend having (.) only be a synonym for map (which would be the method of Functor). > Cale: do you have some real world examples of code you wrote using (.) = > fmap? I haven't used the convention in anything too large, but I've found it rather convenient and natural in the case of, for instance, IO, to be able to write things like map read . lines . getContents. I've played around with it in a lot of small cases and not found ambiguity to be much of a problem. It turns out that the functor is basically always determined by the last thing in the chain of (.) applications, so it remains sensible. > Secondly, I am really fond of the Applicative notation <$>, which goes > great together with <*>. A lighter notation would be nice, but I see no good > way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?) Yeah, that's something to think about. I agree that the appearance of <$> mixes well with the other Applicative operators, and should likely remain a part of that library. Adding special syntactic support for Applicative could be very nice though. - Cale From dave at zednenem.com Thu Apr 24 22:16:46 2008 From: dave at zednenem.com (David Menendez) Date: Thu Apr 24 22:11:30 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <48110482.8070803@gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <48110482.8070803@gmail.com> Message-ID: <49a77b7a0804241916i387d08cke875b228e577ebba@mail.gmail.com> On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven wrote: > Cale Gibbard wrote: > > > > Hello, > > > > In keeping with my small but seemingly extremely controversial > > suggestions for changes to the Prelude, here's a suggestion which I > > think is elegant and worth considering for the Haskell' Prelude: > > > > Rename fmap to map (like it was in Haskell 1.4), and define (.) as a > > synonym for it. > > > > One thing I fear (though that fear may be irrational) is that you get code > that looks like "(.) . ((.) . (.) .)". To me, and I expect to many people, > map and composition are different things, and used in different ways. If > both are written as a dot it will take extra mental effort to decipher the > meaning of a program. The potential for writing code that resembles the > worst outputs of the @pl lambdabot plugin also becomes larger. I'd much rather keep composition and functor map separate. I'm still not entirely sure that generalizing (.) to other morphisms in the Category class is a good idea. Function composition gets used a *lot*, and I imagine we'd loose a lot of inlining if it became a class method. > Secondly, I am really fond of the Applicative notation <$>, which goes > great together with <*>. A lighter notation would be nice, but I see no good > way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?) As much as I like Applicative, I dislike the name "<*>". To me, it makes more sense to use "<$>" for <*>, since it's application of wrapped functions. I've used "$^" as a synonym for fmap (because it's lifted application). It would be nice to have sugar for idiom brackets. You can simulate them with a class, but the result typically doesn't stand out enough visually as being special syntax. -- Dave Menendez From dave at zednenem.com Thu Apr 24 22:24:38 2008 From: dave at zednenem.com (David Menendez) Date: Thu Apr 24 22:19:23 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <404396ef0804231429p132f9c65k4981d6b4060c6c42@mail.gmail.com> <20080423213913.GI22492@scytale.galois.com> Message-ID: <49a77b7a0804241924i7c4d0fc9k9b3f137e200078e3@mail.gmail.com> On Wed, Apr 23, 2008 at 6:21 PM, Niklas Broberg wrote: > > I'm very suspicious about the power/weight ratio of this change. > > Normally, for simple value-level stuff like this, provide both options: > > > > mapM / forM. =<< >>= > > > > So how about, rather than break things, just provide an alternative to ($). > > Alright, I'm not sure what the proper channel for doing this is, but I > reckon here is as good as anywhere. I would like to propose that the > Haskell' Prelude includes the function > > f $$ x = f x > > with the same fixity level as $ (presumably 0) but being left > associative instead. And that $ is left as is. It's a pity that @ isn't available for use as an operator. I've seen it used to represent application in a few places, and its resemblance to an "a" is a handy mnemonic. Is & still free? -- Dave Menendez From cgibbard at gmail.com Fri Apr 25 00:36:06 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri Apr 25 00:30:51 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <49a77b7a0804241916i387d08cke875b228e577ebba@mail.gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <48110482.8070803@gmail.com> <49a77b7a0804241916i387d08cke875b228e577ebba@mail.gmail.com> Message-ID: <89ca3d1f0804242136k13b733dfi17a01732dc2da946@mail.gmail.com> 2008/4/24 David Menendez : > On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven wrote: > > Cale Gibbard wrote: > > > > > > > Hello, > > > > > > In keeping with my small but seemingly extremely controversial > > > suggestions for changes to the Prelude, here's a suggestion which I > > > think is elegant and worth considering for the Haskell' Prelude: > > > > > > Rename fmap to map (like it was in Haskell 1.4), and define (.) as a > > > synonym for it. > > > > > > > One thing I fear (though that fear may be irrational) is that you get code > > that looks like "(.) . ((.) . (.) .)". To me, and I expect to many people, > > map and composition are different things, and used in different ways. If > > both are written as a dot it will take extra mental effort to decipher the > > meaning of a program. The potential for writing code that resembles the > > worst outputs of the @pl lambdabot plugin also becomes larger. > > I'd much rather keep composition and functor map separate. I'm still > not entirely sure that generalizing (.) to other morphisms in the > Category class is a good idea. Function composition gets used a *lot*, > and I imagine we'd loose a lot of inlining if it became a class > method. It should specialise quite nicely. The only places I'd expect you'd lose optimisation would be those which were truly polymorphic applications, which you otherwise couldn't have written as (.) anyway. Someone who knows more about how GHC works might want to comment further, but a simple SPECIALISE pragma for it should do the trick. - Cale From simonpj at microsoft.com Fri Apr 25 03:30:06 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 25 03:24:55 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <4810BF7B.8060809@gmail.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> | The report doesn't actually mention this translation although it is | widely used to implement pattern bindings, and in some compilers (not | GHC) the translation is done before type checking. | | What's interesting to me is that perhaps this gives us a way to | understand what the static semantics of pattern bindings should be, | absent MPB. e.g. Yes, that's a fine point. If this became the formal definition of the *static* semantics of pattern bindings, that would be a significant improvement, because it'd give us a precise way to answer the various questions I asked. (We might or might not like the answers, but at least we could answer them.) Simon From ganesh.sittampalam at credit-suisse.com Fri Apr 25 03:46:30 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Apr 25 03:42:07 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5391CD7@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391CD7@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <78A3C5650E28124399107F21A1FA41945B3362@ELON17P32002A.csfb.cs-group.com> Simon Peyton Jones wrote: > 3. I'm more concerned about the programmer than the implementation. > Consider > (f,g) = (negate, show) > What type do you expect 'f' to have? A straightforward answer might be > f :: (Num a, Show b) => a -> a > If you don't want that, you need to explain a more complicated typing > rule for pattern bindings. I'll ask the same about > (f,g) = (reverse, length) > A simple and consistent story is that all the pattern bound variables > are generalised over all the class constraints and all the type > variables of the RHS. But I bet that is not what you want. I think this is reasonable. In general, something of type (Num a, Show b) => (a -> a, b -> String), might have an occurrence of b hidden inside a -> a. I wouldn't expect specific expressions of this type to be given special treatment. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From apfelmus at quantentunnel.de Fri Apr 25 07:34:35 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Apr 25 07:29:33 2008 Subject: Suggestion regarding (.) and map In-Reply-To: <200804241720.22702.dan.doel@gmail.com> References: <89ca3d1f0804231455n43bf4674n1884e8e59c5509e9@mail.gmail.com> <200804242215.45672.g9ks157k@acme.softbase.org> <200804241720.22702.dan.doel@gmail.com> Message-ID: Dan Doel wrote: > If you do want to generalize (.), you have to decide whether you > want to generalize it as composition of arrows, or as functor application. > The former isn't a special case of the latter (with the current Functor, at > least). By annotating functors with the category they operate on, you can reconcile both seemingly different generalizations class Category (~>) => Functor (~>) f where (.) :: (a ~> b) -> (f a -> f b) -- functor application instance Functor (->) [] where (.) = map -- arrow composition instance Category (~>) => Functor (~>) (d ~>) where (.) = (<<<) Regards, apfelmus From claus.reinke at talk21.com Fri Apr 25 10:09:10 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Apr 25 10:04:09 2008 Subject: RFC: qualified vs unqualified names in defining instance methods Message-ID: <01d701c8a6dd$f28efee0$c7018351@cr3lt> consider Haskell 98 report, section 4.3.2 "Instance Declarations": The declarations d may contain bindings only for the class methods of C. It is illegal to give a binding for a class method that is not in scope, but the name under which it is in scope is immaterial; in particular, it may be a qualified name. (This rule is identical to that used for subordinate names in export lists --- Section 5.2.) For example, this is legal, even though range is in scope only with the qualified name Ix.range. module A where import qualified Ix instance Ix.Ix T where range = ... i consider this confusing (see example at the end), but even worse is that the reference to 5.2 appears to rule out the use of qualified names when defining instance methods. while this abbreviation of qualified names as unqualified names when unambiguous may be harmless in the majority of cases, it seems wrong that the more appropriate explicit disambiguation via qualified names is ruled out entirely. i submit that 4.3.2 should be amended so that qualified names are permitted when defining instance methods. here's an example to show that the unambiguity holds only on the lhs of the method definition, and that the forced use of unqualified names can be confusing: module QI where import Prelude hiding (Functor(..)) import qualified Prelude (Functor(..)) data X a = X a deriving Show instance Prelude.Functor X where fmap f (X a) = X (f a) where q = (reverse fmap,Prelude.fmap not [True],reverse QI.fmap) fmap = "fmap" note that there are two unqualified uses of 'fmap' in the instance declaration, referring to different qualified names: - in the lhs, 'fmap' refers to 'Prelude.fmap', which isn't in scope unqualified, only qualified - in the rhs, 'fmap' refers to 'QI.fmap' claus From ndmitchell at gmail.com Fri Apr 25 10:38:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Apr 25 10:33:31 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0804250738y43e702acm243356cd605c1bcf@mail.gmail.com> Hi Simon, Those additional reasons given are much more compelling, and should definately go on the wiki. I think the essential point is that it makes reasoning about the code simpler - regardless of the effect on implementation. My main remaining reservation is that: (x) /= x x@x /= x It really worries me that (caf) = foo Can be in an entirely different complexity class from caf = foo. It seems like the kind of "refactoring" that beginners will be immediately drawn to, and even experienced programmers will get tripped up on. Anyone doing (caf) is virtually going to be required to add a comment just above stating that the brackets are essential. Does it still work if you relax the definitions so that x@y is a pattern binding only if y is a pattern binding, and (x) is a pattern binding only if x is a pattern binding? Thanks Neil On 4/25/08, Simon Peyton-Jones wrote: > | The report doesn't actually mention this translation although it is > | widely used to implement pattern bindings, and in some compilers (not > | GHC) the translation is done before type checking. > | > | What's interesting to me is that perhaps this gives us a way to > | understand what the static semantics of pattern bindings should be, > | absent MPB. e.g. > > > Yes, that's a fine point. If this became the formal definition of the *static* semantics of pattern bindings, that would be a significant improvement, because it'd give us a precise way to answer the various questions I asked. (We might or might not like the answers, but at least we could answer them.) > > > Simon > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From malcolm.wallace at cs.york.ac.uk Fri Apr 25 10:52:27 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Apr 25 10:47:15 2008 Subject: RFC: qualified vs unqualified names in defining instance methods In-Reply-To: <01d701c8a6dd$f28efee0$c7018351@cr3lt> References: <01d701c8a6dd$f28efee0$c7018351@cr3lt> Message-ID: <87C70C4C-BE6F-4DAA-90D3-0A6B01CC2074@cs.york.ac.uk> > It is illegal to give a binding for a class method that is not in > scope, but the name under which it is in scope is immaterial; in > particular, it may be a qualified name. I believe this was a change introduced in H'98 to tidy up the language. Previously, if a class was imported qualified, it was only possible to declare an instance method by using a qualified name on the lhs. It was felt that this was an oddity, because there are no other situations in which it was even possible to define a variable with an explicitly-qualified name, and in any case the qualification was entirely redundant, because there was no ambiguity. Additionally, permitting a qualified name to appear in the definitional position of any declaration led to ambiguity in parsing. Regards, Malcolm From claus.reinke at talk21.com Fri Apr 25 11:00:21 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Apr 25 10:55:13 2008 Subject: Haskell' - class aliases References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca><638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> Message-ID: <020b01c8a6e5$17eb0920$c7018351@cr3lt> >> Is this the most up-to-date description of the proposal? >> http://repetae.net/recent/out/classalias.html what sounds nice about the class alias proposal is that it is pure sugar, at least to the extent that type aliases are, but the design principle behind it seems to be that there should be a separate class for each method (as in Clean?), and that any compound classes should really just be class aliases (made to look like compound classes by the sugar), so that rearranging compound classes comes down to defining more aliases for the same single-method base classes. since this looks like class equivalence plus namespace handling, i was wondering how far one could get without the proposed extension. this is slightly more difficult than the proposed translation (which splits compound aliases into their components, so that the alias class is always translated away), but it might still be of interest. consider the 'class alias FooBar a = (Foo a,Bar a)' example from the proposal page. we define FooBar and Foor/Bar in separate modules and use that for namespace management. - FooAndBar defines Foo and Bar, as well as a type X which is an instance of both - FooBar defines FooBar, implicit derivations of FooBar from Foo/Bar and vice-versa (the aliasing part), as well as a type Y which is an instance of FooBar FooBar also arranges for Y to be an instance of Foo/Bar, and for X to be an instance of FooBar, via the implicit derivations, but controlled by instances of How note the class 'How' and its instances, which ensure that any type class instance is either defined, or derived (in a unique, specified way), but never both. problems: (1) instance method definitions by qualified names are not permitted, leading to the confusing 'foo = foo' (cf separate thread) (2) overlapping instances, due to the derived instances; it seems this can be held in check by the use of 'How', at the expense of some extra parameters/contexts/ instances to control how each instance is defined/derived example session: *FooBar> foo (X 1) False *FooBar> bar 0 (X 1) [X 1] *FooBar> foo (Y 1) True *FooBar> bar 0 (Y 1) [Y 1,Y 1] *FooBar> FooAndBar.foo (X 1) False *FooBar> FooAndBar.foo (Y 1) True *FooBar> FooAndBar.bar 0 (X 1) [X 1] *FooBar> FooAndBar.bar 0 (Y 1) [Y 1,Y 1] *FooBar> :t foo foo :: (FooBar a how) => a -> Bool *FooBar> :t FooAndBar.foo FooAndBar.foo :: (Foo a how) => a -> Bool *FooBar> :t bar bar :: (FooBar a how) => Int -> a -> [a] *FooBar> :t FooAndBar.bar FooAndBar.bar :: (Bar b how) => Int -> b -> [b] i don't think i'd recommend this encoding style (it does not quite fullfill the criterion of simplicity!-), but there you are: class aliases encoded. hth, claus ps. (for the TF vs FD fans: replacing FD class 'How' with a TF doesn't seem to work; a bug?) -------------- next part -------------- A non-text attachment was scrubbed... Name: FooAndBar.hs Type: application/octet-stream Size: 767 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20080425/c3555a23/FooAndBar.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: FooBar.hs Type: application/octet-stream Size: 1381 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20080425/c3555a23/FooBar.obj From simonpj at microsoft.com Fri Apr 25 12:37:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Apr 25 12:32:03 2008 Subject: Haskell' - class aliases In-Reply-To: <20080423041823.GX17560@sliver.repetae.net> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> John OK here's a question about class alisas. You propose: class Foo a where foo :: a -> [a] foo x = [] class Bar a where bar :: a -> a bar x = [x] class alias FooBar a = (Foo a, Bar a) where foobar :: a -> a foobar x = x foo x = bar x I have a few minor questions about this that'd be worth clarifying on your main page (a) I assume you can add a method 'foobar' not declared in either Foo or Bar. Your very first example has this. But it's contradicted later when you say that "One can declare an instance of Num either by giving separate instances for Eq, Additive, Multiplicative" (b) And I assume that you don't need to repeat the type signatures for 'foo' and 'bar'. (c) I think you intend that you can override the default methods for foo and bar; and I have done so for method 'foo'. Question: how does the above differ from this? class (Foo a, Bar a) => FooBarSC a where foobar :: a -> a Here Foo, Bar are simply superclasses. From the point of view of a type signature there *no* difference: f :: (FooBarSC a) => ... gives access to all the methods of Foo and Bar. So what's the difference? Answer (I believe): when you give an instance of FooBar you give implementations for all methods of Foo, Bar, and FooBar. So the obvious question is: do we really need a new construct? Why not just use FooBarSC? Then we'd have to allow you to give implementations for superclass methods too: instance FooBarSC Int where foobar = ... foo = ... bar = ... I think I believe (like you) that this is a bad idea. The main reason is that it's a totally unclear whether, given a FooBarSC Int instance declaration, should there be an instance for (Foo Int), always, never, or optionally? However, I think you might want to articulate the reasons carefully, because we have two features that are really extremely close. To put it another way, you could imagine re-expressing your proposal like this: class (Eq a) && (Additive a, Multiplicative a) => Num a meaning this: when you give an instance for (FooBar T) you * MUST give implementations for the methods of Addititive and Applicative * MUST NOT give implementations for methods of Eq; rather the Eq T instance must be in scope. This is, I believe, what you mean by class alias Num a = Eq a => (Additive a, Multiplicative a) Now I'm not necessarily suggesting this as concrete syntax. But my point is that you're really asking for small modification of the existing superclass mechanism, that divides the superclasses into two groups, the "flat" ones (like Additive and Multiplicative) and the "nested" ones (like Eq). Is that right? If so, a syntax that is more suggestive of the current superclass declaration looks better to me. This close relationship also suggests strongly that the answer to (a) above should be 'yes', since you can certainly add methods to a class with superclasses. I won't say more until I'm sure I've understood your intent. Simon From iavor.diatchki at gmail.com Fri Apr 25 13:12:36 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri Apr 25 13:07:19 2008 Subject: RFC: qualified vs unqualified names in defining instance methods In-Reply-To: <01d701c8a6dd$f28efee0$c7018351@cr3lt> References: <01d701c8a6dd$f28efee0$c7018351@cr3lt> Message-ID: <5ab17e790804251012x68513789v9125ab87d4d2615b@mail.gmail.com> Hello, I think that the H98 change was a good one. Qualified names should only be used in _uses_ of variables (to disambiguate) and not in definitions because (hopefully) there is nothing to disambiguate in a definition. By the way, method definitions already have a distinction between what is on the LHS and what is on the RHS. For example, consider the following instance: instance Show a => Show (Maybe a) where show Nothing = "Nothing" show (Just a) = "Just " ++ show a Here "show" is not a recursive function because the "show" on the RHS is different from the "show" on the LHS. So my preference is to keep the status quo on this issue. -Iavor On Fri, Apr 25, 2008 at 7:09 AM, Claus Reinke wrote: > consider Haskell 98 report, section 4.3.2 "Instance Declarations": > > The declarations d may contain bindings only for the class methods of C. > It is illegal to give a binding for a class method that is not in scope, but > the name under which it is in scope is immaterial; in particular, it may > be a qualified name. (This rule is identical to that used for subordinate > names in export lists --- Section 5.2.) For example, this is legal, even > though range is in scope only with the qualified name Ix.range. > module A where > import qualified Ix > > instance Ix.Ix T where > range = ... > > i consider this confusing (see example at the end), but even > worse is that the reference to 5.2 appears to rule out the use of qualified > names when defining instance methods. > > while this abbreviation of qualified names as unqualified names when > unambiguous may be harmless in the majority of cases, it > seems wrong that the more appropriate explicit disambiguation > via qualified names is ruled out entirely. > i submit that 4.3.2 should be amended so that qualified names are permitted > when defining instance methods. > > here's an example to show that the unambiguity holds only on the > lhs of the method definition, and that the forced use of unqualified > names can be confusing: > > module QI where > import Prelude hiding (Functor(..)) > import qualified Prelude (Functor(..)) > data X a = X a deriving Show > instance Prelude.Functor X where fmap f (X a) = X (f a) > where q = (reverse fmap,Prelude.fmap not [True],reverse QI.fmap) > fmap = "fmap" > > note that there are two unqualified uses of 'fmap' in the instance > declaration, referring to different qualified names: > - in the lhs, 'fmap' refers to 'Prelude.fmap', which isn't in scope > unqualified, only qualified > > - in the rhs, 'fmap' refers to 'QI.fmap' > > claus > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From claus.reinke at talk21.com Fri Apr 25 13:41:09 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Apr 25 13:35:58 2008 Subject: RFC: qualified vs unqualified names in defining instance methods References: <01d701c8a6dd$f28efee0$c7018351@cr3lt> <5ab17e790804251012x68513789v9125ab87d4d2615b@mail.gmail.com> Message-ID: <027b01c8a6fb$8d3df870$c7018351@cr3lt> > I think that the H98 change was a good one. Qualified names should > only be used in _uses_ of variables (to disambiguate) and not in > definitions because (hopefully) there is nothing to disambiguate in a > definition. i was not suggesting to disallow the unqualified def (even though it irks me as an unneccesary exception). only that i be allowed to use a qualified name to make the code less confusing to read (not to mention that the qualified name is in scope, the unqualified name isn't..). > By the way, method definitions already have a distinction between what > is on the LHS and what is on the RHS. For example, consider the > following instance: > > instance Show a => Show (Maybe a) where > show Nothing = "Nothing" > show (Just a) = "Just " ++ show a > > Here "show" is not a recursive function because the "show" on the RHS > is different from the "show" on the LHS. actually, both 'show's refer to the same thing here, method 'show' in class 'Show', and the disambiguation is via the types. now compare this with an instance from the class alias encoding i posted in the other thread: instance (FooBar a how, How (CFoo a) (Derived (CFooBar a))) => Foo a (Derived (CFooBar a)) where foo = foo is it obvious to you which foo refers to what? and though it looks similar to your example, the disambiguation is not via types (alone), but via what is in scope, plus the exception that i can/have to refer to something that isn't in scope on the left hand side. for reference (spoiler ahead;-), in this example: - 'Foo' is in scope as both 'FooAndBar.Foo' and 'Foo' - the lhs 'foo' is not in scope, but refers to 'FooAndBar.foo', which is in scope - the rhs 'foo' is in scope as both 'FooBar.foo' and 'foo', and comes from 'FooBar a how', not from any 'Foo' in the same module, we have: class How (CFooBar a) how => FooBar a how where foo :: a -> Bool foo _ = True bar :: Int -> a -> [a] here, the lhs 'foo' refers to 'FooBar.foo', which is also in scope as 'foo', and belongs to class 'FooBar'! so the left hand side 'foo's in the definitions refer to different things. i originally filed this as a bug, until Simon PJ kindly pointed me to the Haskell 98 report, which forces GHC to behave this way.. i guess i'll remember this oddity for a while, so i can live with it, but if it is irksome that the report allows me to refer to a name that is not in scope, it is far from obvious why it needs to prevent me from referring to a name that *is* in scope (Malcolm mentioned parsing ambiguities as the reason for this, but in my case, GHC recognizes the qualified name and *complains* about it). claus From marlowsd at gmail.com Fri Apr 25 18:00:50 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Apr 25 17:55:43 2008 Subject: RFC: qualified vs unqualified names in defining instance methods In-Reply-To: <027b01c8a6fb$8d3df870$c7018351@cr3lt> References: <01d701c8a6dd$f28efee0$c7018351@cr3lt> <5ab17e790804251012x68513789v9125ab87d4d2615b@mail.gmail.com> <027b01c8a6fb$8d3df870$c7018351@cr3lt> Message-ID: <48125492.7070804@gmail.com> Claus Reinke wrote: > i originally filed this as a bug, until Simon PJ kindly pointed > me to the Haskell 98 report, which forces GHC to behave > this way.. i guess i'll remember this oddity for a while, so > i can live with it, but if it is irksome that the report allows > me to refer to a name that is not in scope, it is far from obvious why > it needs to prevent me from referring to a > name that *is* in scope (Malcolm mentioned parsing > ambiguities as the reason for this, but in my case, GHC > recognizes the qualified name and *complains* about it). Is it too hard to remember that in an instance declaration you can give bindings for methods of the class being instantiated only? To me, the oddity is that the method name must be in scope at all - this is a definition, not a reference, with a fixed set of things that can be defined. However, there is a consistency issue with record construction. The fields of a record construction are very much like the methods in an instance declaration: they are bindings for already-defined identifiers, and the set of available identifiers is known statically. In Haskell 98: aexp -> qcon { fbind1 , ... , fbindn } fbind -> qvar = exp so record fields can be referred to by qualified names, and in fact you are required to use the name by which the field is in scope - but GHC's DisambiguateRecordFields extension relaxes this so you're allowed to use the unqualified name. So, in summary: - Haskell 98 is completely inconsistent here. - GHC + DisambiguateRecordFields is a bit more consistent in that unqualified names are allowed in both settings, but still allows qualified names in one setting but not the other. So whatever we do we should be consistent. It would be slightly strange if record construction required the unqualified name, but record update required the qualified name, when the field name is only in scope qualified. So that indicates that we should allow either form in record construction (and instance declaration), i.e. Claus's suggestion + DisambiguateRecordFields. Cheers, Simon From john at repetae.net Fri Apr 25 19:45:55 2008 From: john at repetae.net (John Meacham) Date: Fri Apr 25 19:40:36 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> <20080423041823.GX17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE539247D@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080425234555.GG17560@sliver.repetae.net> On Fri, Apr 25, 2008 at 05:37:17PM +0100, Simon Peyton-Jones wrote: > John > > OK here's a question about class alisas. You propose: > > class Foo a where > foo :: a -> [a] > foo x = [] > class Bar a where > bar :: a -> a > bar x = [x] > > class alias FooBar a = (Foo a, Bar a) where > foobar :: a -> a > foobar x = x > > foo x = bar x > > I have a few minor questions about this that'd be worth clarifying on your main page > (a) I assume you can add a method 'foobar' not declared > in either Foo or Bar. Your very first example has this. > But it's contradicted later when you say that "One can declare an instance > of Num either by giving separate instances for Eq, Additive, Multiplicative" No, I didn't mean to imply that. as you noted, that would mean that an alias would not be a simple preprocessing. what you can do is create a real class FooBar which has both foo and bar as superclasses, then create an alias for all three so you can create a single instance to define all three. It might be possible to add this though and have it automatically create an appropriate class and a class alias. but I think that might muddy the intent of class aliases if not all can be described as simple aliases for other existing classes. So we can reserve that as a possible future extension. it is easy enough to manually create the 'foobar' containing class in any case and if you don't export it from your module, you get the equivalent effect. > > (b) And I assume that you don't need to repeat the type > signatures for 'foo' and 'bar'. Yup, no need to repeat type signatures. > > (c) I think you intend that you can override the default methods > for foo and bar; and I have done so for method 'foo'. Yes. being able to override default instances is a key part, otherwise you wouldn't be able to, for instance, create appropriate 'Num' compatible methods from your advanced 'NewNum' class alias. But you are not forced to do so. > > Question: how does the above differ from this? > > class (Foo a, Bar a) => FooBarSC a where > foobar :: a -> a > > Here Foo, Bar are simply superclasses. From the point of view of a type signature there *no* difference: > > f :: (FooBarSC a) => ... > > gives access to all the methods of Foo and Bar. So what's the difference? > > Answer (I believe): when you give an instance of FooBar > you give implementations for all methods of > Foo, Bar, and FooBar. Yes, it is because you cannot declare an instance of FooBarSC and have it also create the ones for Foo and Bar, and because you can't create new default instances for 'foo' and 'bar' that refer to 'foobar'. > > So the obvious question is: do we really need a new construct? Why > not just use FooBarSC? Then we'd have to allow you to give > implementations for superclass methods too: > instance FooBarSC Int where > foobar = ... > foo = ... > bar = ... > > I think I believe (like you) that this is a bad idea. The main reason > is that it's a totally unclear whether, given a FooBarSC Int instance > declaration, should there be an instance for (Foo Int), always, never, > or optionally? Yes. and it breaks one of the major haskell properties I am not willing to give up, That when you add an import to your module (or any module you depend on), your program will either fail to compile or have the _exact_ same meaning. > However, I think you might want to articulate the reasons carefully, > because we have two features that are really extremely close. Yes, I think the above might help with the lattice case, where you have a strict hierarchy of classes and the superclass tree mirrors your class aliases, but this may not be the case in general. in particular, we don't want to necessarily redo the numeric hierarchy as a strict generalization or splitting up of the current prelude numerical hierarchy, and the superclass method gets a little hairy when you want to do things like that and don't want to end up with every method in its own class. > To put it another way, you could imagine re-expressing your proposal > like this: > > class (Eq a) && (Additive a, Multiplicative a) => Num a > > meaning this: when you give an instance for (FooBar T) you > > * MUST give implementations for the methods of Addititive and > Applicative > > * MUST NOT give implementations for methods of Eq; rather the Eq T > instance must be in scope. > > This is, I believe, what you mean by class alias Num a = Eq a => > (Additive a, Multiplicative a) > > Now I'm not necessarily suggesting this as concrete syntax. But my > point is that you're really asking for small modification of the > existing superclass mechanism, that divides the superclasses into two > groups, the "flat" ones (like Additive and Multiplicative) and the > "nested" ones (like Eq). Is that right? If so, a syntax that is more > suggestive of the current superclass declaration looks better to me. Hmm.. I consider class aliases orthogonal and complementary to superclasses, rather than a generalization of them. I do not think that what one wants out of a superclass hierarchy and a class alias collection (note, I don't say hierarchy) will be the same and having them mirror each other will create a tension between the two in how one designs their code. > This close relationship also suggests strongly that the answer to (a) > above should be 'yes', since you can certainly add methods to a class > with superclasses. Yeah, I disagree here, mainly because I don't want to conflate superclasses with class aliases. I feel they have different uses, even though they can sometimes achieve the same thing. Part of this is my 'sather' heritige, sather was a pretty cool fully type safe (in the stronger FP sense moreso than the java sense) object oriented language that was somewhat based on eiffel, but with the advantage of being designed by people with a stronger grasp of type theory than the eiffel designer. One of its major innovations was a separation of code reuse from class inheritance. In traditional object oriented languages, inheritance is both a method of code reuse (by defining non abstract superclasses with virtual methods that can be overridden), and of expressing a strong relationship between the types. However the sather designers realized these two things were not necessarily related, their solution was to define superclasses as _always_ being abstract, and having a different mechanism for code reuse. It was quite nice. enough so that I started (not as elegantly) using that approach in other OO languages I was using. Had I not discovered Haskell, I would likely still be the sather language maintainer :) I believe that class aliases define a method of code (instance method in particular) reuse. When you define your 'HaskellPrimePrelude' instances, you want the code to automatically and transparently be used to define 'Haskell98Prelude' instances, likewise, when you define 'Haskell98Prelude' instances, you want the code to automatically and transparently define 'HaskellPrimePrelude' instances. However, there is no clear superclass relationship between the two and being forced to introduce an artificial one would obfuscate things I think. John -- John Meacham - ?repetae.net?john? From twanvl at gmail.com Fri Apr 25 19:50:53 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Fri Apr 25 19:45:35 2008 Subject: Haskell' - class aliases In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480CD7BB.2040601@gmail.com> <480CDF83.3090904@mcmaster.ca> <638ABD0A29C8884A91BC5FB5C349B1C32AE53041F5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <48126E5D.1070102@gmail.com> Simon Peyton-Jones wrote: > Is this the most up-to-date description of the proposal? > http://repetae.net/recent/out/classalias.html Has anyone looked at my (confusingly named and horribly written) variant? http://haskell.org/haskellwiki/Superclass_defaults My idea is to split class aliases into two separate things: 1. Superclass defaults: allow a class declaration to contain defaults for methods from superclasses. Allow an instance declaration to be for multiple classes at once, using the most specific defaults: instance (FooBar a, Foo a, Bar a) -- pick the defaults from FooBar, since it is a subclass -- of both Foo and Bar. 2. Class aliases: simply an alias for zero or more classes. class alias FooAndBar a = (Foo a, Bar a) In a context FooAndBar a is simply replaced by (Foo a, Bar a). For instantiation purposes the class alias could override the default methods as if it was a subclass of Foo and Bar. No new methods can be added. Alternatively class aliases could be just macros, like type synonyms. Part 1 applies for instance to the Functor/Applicative/Monad hierarchy, fmap could have a default in terms of (>>=). Part 2 is useful for splitting classes up into smaller bits. Twan From john at repetae.net Fri Apr 25 19:51:35 2008 From: john at repetae.net (John Meacham) Date: Fri Apr 25 19:46:16 2008 Subject: Haskell' - class aliases In-Reply-To: <200804242221.03492.g9ks157k@acme.softbase.org> References: <480CD7BB.2040601@gmail.com> <200804242048.15740.g9ks157k@acme.softbase.org> <20080424192750.GE17560@sliver.repetae.net> <200804242221.03492.g9ks157k@acme.softbase.org> Message-ID: <20080425235135.GH17560@sliver.repetae.net> On Thu, Apr 24, 2008 at 10:21:03PM +0200, Wolfgang Jeltsch wrote: > Am Donnerstag, 24. April 2008 21:27 schrieb John Meacham: > > On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote: > > [?] > > > > I also have some remark: Why not write > > > > > > > class Eq a => Num a = (Additive a, Multiplicative a) > > > > > > instead of > > > > > > > class Num a = Eq a => (Additive a, Multiplicative a) > > > > Well, because you can think of 'Num a' as an alias for 'Eq a => > > (Additive a, Multiplicative a)', not that Eq is a superclass of Num > > which the class declaration syntax implies. > > Hmm, in what way is Num a an alias for Eq a => (Additive a, Multiplicative a)? > You cannot write this: > > > square :: (Eq a => (Additive a, Multiplicative a)) => a -> a > > I would say: ?Under the condition that Eq a holds, Num a is an alias for > (Additive a, Multiplicative a). And this seems to be perfectly expressed by > my above proposal. Hmm... I guess it depends on how you think about it. I tend to think about them in terms of what they are rewritten to rather than a proposition about classes. but perhaps that makes more sense. Will mull on it some.. John -- John Meacham - ?repetae.net?john? From lennart at augustsson.net Sat Apr 26 15:35:39 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Apr 26 15:30:21 2008 Subject: Meta-point: backward compatibility In-Reply-To: <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> <404396ef0804240121u3485abbcjddc828b6d7b5b4ca@mail.gmail.com> Message-ID: I agree with Neil. Translators are very difficult to do right, except for the most trivial transformations. Changing tabs to spaces is about as far as I would trust an automatic translator. -- Lennart On Thu, Apr 24, 2008 at 9:21 AM, Neil Mitchell wrote: > Hi > > I think Henrik's criteria are pretty close to perfect. > > > As I have argued before on the committee list, I also think we should > *not* > > worry about backwards incompatible changes too much in cases where a > simple > > automatic translation from H98 to H' code is possible. Even for a large > > project, it is IMHO no big hardship to run a H98->H' translator over all > > Haskell sources. > > Some questions: > > 1) Will I (the programmer) have to mode switch in painful ways between > H98 and H'? Do I have to learn a pile of exceptions, or is there some > common rule that works? (i.e. removing n+k is fine since I just don't > learn it, changing the fixity of $ is not since I need to know both) > > 2) Will tool T (the translator) work on academic papers that have > previously been published. > > 3) Will tool T handle all of GHC's extensions. > > 4) Will tool T deal with things like CPP, hsc, trhsx, happy, alex > etc... - all these file formats which include embedded Haskell. > > 5) Will tool T ever exist. > > I think the answer to 2-5 is nearly certainly going to be "No". I > don't think the relevance of a conversion tool should even be > considered until some person steps forward and says without doubt that > _they_ will write the converter. Even if they did there very best, it > still won't be trivial to use in all cases. > > > As John Launchbury has said, given Haskell's current rise in popularity, > anything that > > we do not fix with H' will be much harder, if not impossible, to fix in > the future. > > That is a very good point. Perhaps we're already a little too late. > > Thanks > > Neil > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20080426/857ef3f7/attachment.htm From iavor.diatchki at gmail.com Sat Apr 26 16:20:35 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Apr 26 16:15:14 2008 Subject: RFC: qualified vs unqualified names in defining instance methods In-Reply-To: <48125492.7070804@gmail.com> References: <01d701c8a6dd$f28efee0$c7018351@cr3lt> <5ab17e790804251012x68513789v9125ab87d4d2615b@mail.gmail.com> <027b01c8a6fb$8d3df870$c7018351@cr3lt> <48125492.7070804@gmail.com> Message-ID: <5ab17e790804261320i18915128y535f21a932d17626@mail.gmail.com> Hello, On Fri, Apr 25, 2008 at 3:00 PM, Simon Marlow wrote: > ... > It would be slightly strange if record construction required the > unqualified name, but record update required the qualified name, when the > field name is only in scope qualified. So that indicates that we should > allow either form in record construction (and instance declaration), i.e. > Claus's suggestion + DisambiguateRecordFields. My preference would be to disallow qualified names in: (i) the method names of instances, (ii) record construction (C { l = e }), (iii) record patterns (C { l = p }). I think that this is consistent, and it easy easy to see what the labels refer to: in the case of instances, the method belongs to the class in question (which can be qualified), and in the case of records the label belongs to the specified constructor (which can also be qualified). As Simon points out, record updates still require qualified names but I don't think that there is an inconsistency there because I think of record updates as the application of a (oddly named) function, just like record selection is the application of a (normally named) function. Therefore, it makes sense that we may have to use qualified names to disambiguate which function we are referring to. -Iavor From chak at cse.unsw.edu.au Sun Apr 27 22:27:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Apr 27 22:22:00 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <78A3C5650E28124399107F21A1FA41945B3359@ELON17P32002A.csfb.cs-group.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <89ca3d1f0804222354j73296e98pee5c0c1cc8ea49eb@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334C@ELON17P32002A.csfb.cs-group.com> <89ca3d1f0804230106u43e42402m8ed8a3d6a1d24425@mail.gmail.com> <78A3C5650E28124399107F21A1FA41945B334E@ELON17P32002A.csfb.cs-group.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> <78A3C5650E28124399107F21A1FA41945B3359@ELON17P32002A.csfb.cs-group.com> Message-ID: <33FB3F06-5C6E-4991-9C07-341455699EC4@cse.unsw.edu.au> Sittampalam, Ganesh: > Manuel Chakravarty wrote: >> We should be careful about where we break existing code, and >> we should try to support automatic translation of H98 to H' code, >> but any changes that we do not make now will become even more >> difficult in the future when there is even more Haskell code. >> Look at what is happening now already, industrial users applying >> pressure on the committee to not change the language too much >> for the sake of legacy code. A clear indication that anything >> we don't change now, we will have to live with forever. > > I wasn't arguing for special treatment as an "industrial" user, > just listing one datapoint that I have to counter any impression > that the only or main cost to the community as a whole is fixing > what's on hackage. I agree with that. However, maybe somewhat paradoxically, I think, given the resistance that changes to the language already invoke now, we should actually be fairly aggressive with changes this one time (ie, in Haskell'). >> Hence, anything that is *important* to change, we should change now. > > Agreed. It's just in this case the pain of changing will be huge and > the benefits marginal at best. Yes, I was not arguing for that particular change, my comment was of a general nature. >> We should mitigate the pain by having a H98 to H' translator > > Such a translator would have to maintain existing layout etc, and > produce reasonably nice looking code in places where it makes changes. > Do we have any infrastructure that would make writing one easy? For H98, simple[1] changes might be possible with haskell-src if it would be modified to be able to preserve comments and layout. Manuel [1] For example, purely syntactic ones. From chak at cse.unsw.edu.au Mon Apr 28 00:29:48 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Apr 28 00:24:26 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <200804242127.31837.g9ks157k@acme.softbase.org> References: <20080422225339.GA27585@haskell.galois.com> <78A3C5650E28124399107F21A1FA41945B3357@ELON17P32002A.csfb.cs-group.com> <200804242127.31837.g9ks157k@acme.softbase.org> Message-ID: <45017F06-7DD5-4AE8-A734-7366D464EC9B@cse.unsw.edu.au> 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 From chak at cse.unsw.edu.au Mon Apr 28 00:32:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Apr 28 00:27:33 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: Lennart Augustsson: > Haskell has now reached the point where backwards compatibility is > something that must be taken very seriously. > The motivation behind Haskell' was to bring the most common > extensions into the standard, it was all going to be done in a year. > Haskell' is not a new language, but growing Haskell98 with common > extension. > If there's something in Haskell' that will require a change every > 1000 lines, then I think it's acceptable. > If there's something in Haskell' that will require changing every > other line, then it's not acceptable. The existing Haskell codes > bases are simply too big. I completely agree. > So I still think changing $ is insane. Why change? If you want a > new operator, make a new one. Don't make a gratuitous change that > will waste countless man hours. For me it's a simple decision, if $ > changes I cannot use Haskell'. :( Given that people can't even agree whether it makes sense to change $ at all, this is IMHO far away from a change that justifies breaking any code. Manuel From marlowsd at gmail.com Mon Apr 28 12:42:10 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 28 12:36:45 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4815FE62.4060102@gmail.com> Simon Peyton-Jones wrote: > | The report doesn't actually mention this translation although it is > | widely used to implement pattern bindings, and in some compilers (not > | GHC) the translation is done before type checking. > | > | What's interesting to me is that perhaps this gives us a way to > | understand what the static semantics of pattern bindings should be, > | absent MPB. e.g. > > Yes, that's a fine point. If this became the formal definition of the *static* semantics of pattern bindings, that would be a significant improvement, because it'd give us a precise way to answer the various questions I asked. (We might or might not like the answers, but at least we could answer them.) Ok. So I counter-propose that we deal with pattern bindings like this: The static semantics of a pattern binding are given by the following translation. A binding 'p = e' has the same meaning as the set of bindings z = e x1 = case z of { p -> x1 } ... xn = case z of { p -> xn } where z is fresh, and x1..xn are the variables of the pattern p. For bang patterns, I think it suffices to say that a bang at the top level of p is carried to the binding for z, and then separately define what banged variable bindings mean (i.e. add appropriate seqs). Does anyone see any problems with this? Oh, and I also propose to use the terminology "variable binding" instead of "simple pattern binding", which is currently used inconsistently in the report (see section 4.4.3.2). Cheers, Simon From marlowsd at gmail.com Mon Apr 28 12:56:10 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 28 12:50:45 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> Message-ID: <481601AA.4070802@gmail.com> Manuel M T Chakravarty wrote: > Lennart Augustsson: >> So I still think changing $ is insane. Why change? If you want a new >> operator, make a new one. Don't make a gratuitous change that will >> waste countless man hours. For me it's a simple decision, if $ >> changes I cannot use Haskell'. :( > > Given that people can't even agree whether it makes sense to change $ at > all, this is IMHO far away from a change that justifies breaking any code. So I suggest we reject the proposal, and move any further discussion to haskell-cafe. Ok? Cheers, Simon From iavor.diatchki at gmail.com Mon Apr 28 13:27:54 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Apr 28 13:22:28 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <4815FE62.4060102@gmail.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> <4815FE62.4060102@gmail.com> Message-ID: <5ab17e790804281027r6e80273axd31c8ea6bc72632c@mail.gmail.com> Hi, On Mon, Apr 28, 2008 at 9:42 AM, Simon Marlow wrote: > Ok. So I counter-propose that we deal with pattern bindings like this: > > The static semantics of a pattern binding are given by the following > translation. A binding 'p = e' has the same meaning as the set of > bindings > > z = e > x1 = case z of { p -> x1 } > ... > xn = case z of { p -> xn } > > where z is fresh, and x1..xn are the variables of the pattern p. > > For bang patterns, I think it suffices to say that a bang at the top level > of p is carried to the binding for z, and then separately define what banged > variable bindings mean (i.e. add appropriate seqs). > > Does anyone see any problems with this? Seems good to me. > Oh, and I also propose to use the terminology "variable binding" instead of > "simple pattern binding", which is currently used inconsistently in the > report (see section 4.4.3.2). This also makes sense. Perhaps, we should use "strict variable binding" instead of "banged variable binding" as well? -Iavor From marlowsd at gmail.com Mon Apr 28 13:39:09 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 28 13:33:43 2008 Subject: Composition again In-Reply-To: <480CFAD1.7070205@gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> <480CFAD1.7070205@gmail.com> Message-ID: <48160BBD.9060900@gmail.com> Simon Marlow wrote: > Here are the possibilities for composition: > > 0. do nothing > 1. use a Unicode operator for composition > 2. require spaces around . as an operator > 3. require spaces around all operators > 4. use another ASCII operator for composition, e.g. <<< > > Nothing has been decided yet, but most of the committee tends to favour > (2), with some expressing a slight preference for (0). We've pretty > much ruled out (1) and (3) as too radical, and as you say using Unicode > is still too impractical. > > There is some uncertainty about the precise details of (2), and thinking > about that is what lead to my proposal about changing the syntax of > qualified operators. Ok, I'm going to try to make some progress on this. I think it's fair to say that the only possible options are (0) do nothing, or (2) require spaces around "." as an operator. I'll explore how we might do (2). We discussed this a bit on the committee mailing list, here's where we got to. The proposal amounts to making certain sequences illegal. Let's try to implement the informal rule dot is only allowed adjacent to a varid or conid when it is part of a qualified name so that would make these illegal: length.lines (.f) (f.) ++.x x.++ Just.(+1) Here's an interesting case: [Monday..Friday] which I imagine we would like to be legal. (currently it's illegal, or rather 'Monday..' is interpreted as a qualified operator; see separate proposal for changing the syntax of qualified operators). The way to implement this is to add the following productions to the lexical syntax: reservedlexeme ::= ({symbol} '.') (varid | conid) | (varid | conid) ('.' {symbol}) The idea is that reservedlexemes are illegal, and work via the maximal-munch rule. (note that this version relies on the alternate qualified operator syntax proposal, because it makes the existing qualified operator syntax into a reservedlexeme). My personal view is that this is somewhat ugly. However, it does have the benefit of releasing the 'foo.x' syntax for future use, e.g. in a new record system - but some people find that a bit tasteless too, and I might be inclined to agree. Thoughts? Cheers, Simon From johan.tibell at gmail.com Mon Apr 28 14:57:55 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Apr 28 14:52:29 2008 Subject: patch applied (haskell-prime-status): add ""Make $ left associative, like application" In-Reply-To: <481601AA.4070802@gmail.com> References: <20080422225339.GA27585@haskell.galois.com> <480E72EE.5030703@gmail.com> <1208942252.27748.160.camel@localhost> <200804230542.21570.dan.doel@gmail.com> <1056838947.20080423135550@gmail.com> <481601AA.4070802@gmail.com> Message-ID: <90889fe70804281157h645731c1q3ed1af3a88ec1f77@mail.gmail.com> On Mon, Apr 28, 2008 at 6:56 PM, Simon Marlow wrote: > So I suggest we reject the proposal, and move any further discussion to > haskell-cafe. Ok? Sounds good to me. From igloo at earth.li Mon Apr 28 15:25:24 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Apr 28 15:19:57 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <4815FE62.4060102@gmail.com> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> <4815FE62.4060102@gmail.com> Message-ID: <20080428192524.GA2332@matrix.chaos.earth.li> On Mon, Apr 28, 2008 at 09:42:10AM -0700, Simon Marlow wrote: > > Ok. So I counter-propose that we deal with pattern bindings like this: > > The static semantics of a pattern binding are given by the following > translation. A binding 'p = e' has the same meaning as the set of > bindings > > z = e > x1 = case z of { p -> x1 } > ... > xn = case z of { p -> xn } > > where z is fresh, and x1..xn are the variables of the pattern p. Just to check, this is saying "no change relative to Haskell 98" (although perhaps specifying it less ambiguously), right? > Oh, and I also propose to use the terminology "variable binding" instead > of "simple pattern binding", Good idea. Thanks Ian From igloo at earth.li Mon Apr 28 16:00:52 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Apr 28 15:55:26 2008 Subject: Composition again In-Reply-To: <48160BBD.9060900@gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> <480CFAD1.7070205@gmail.com> <48160BBD.9060900@gmail.com> Message-ID: <20080428200052.GB2332@matrix.chaos.earth.li> On Mon, Apr 28, 2008 at 10:39:09AM -0700, Simon Marlow wrote: > > Ok, I'm going to try to make some progress on this. I think it's fair > to say that the only possible options are (0) do nothing, or (2) require > spaces around "." as an operator. If we are considering requiring spaces around "." then I think it would make sense to also consider requiring spaces around * "-" (so we can make "-2" and "map (- 3) xs" both do what you expect) * "!" (meaning that "f !x" isn't valid but differently parsed for patterns and expressions - assuming we plan to accept BangPatterns). I don't think it makes sense to make a special case for requiring spaces around "$", as TH won't be in H'. Thanks Ian From niklas.broberg at gmail.com Mon Apr 28 16:06:38 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Apr 28 16:01:12 2008 Subject: Composition again In-Reply-To: <20080428200052.GB2332@matrix.chaos.earth.li> References: <20080415181344.GA29673@haskell.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> <480CFAD1.7070205@gmail.com> <48160BBD.9060900@gmail.com> <20080428200052.GB2332@matrix.chaos.earth.li> Message-ID: > I don't think it makes sense to make a special case for requiring spaces > around "$", as TH won't be in H'. I agree, there's absolutely no need to treat $ differently in H'. The situation will already be better than it is now, since by the special treatment of . (and - and !, which I also agree with), there will be a precedent to follow (assuming it gets accepted of course). That alone makes it much easier to define the meaning of extensions like $ in TH. Cheers, /Niklas From marlowsd at gmail.com Mon Apr 28 17:28:29 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Apr 28 17:23:07 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <20080428192524.GA2332@matrix.chaos.earth.li> References: <480F72A8.2080401@gmail.com> <5ab17e790804231315l3c4bc79dgff88b98fd55b46fa@mail.gmail.com> <4810BF7B.8060809@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE5391FD5@EA-EXMSG-C334.europe.corp.microsoft.com> <4815FE62.4060102@gmail.com> <20080428192524.GA2332@matrix.chaos.earth.li> Message-ID: <4816417D.6070105@gmail.com> Ian Lynagh wrote: > On Mon, Apr 28, 2008 at 09:42:10AM -0700, Simon Marlow wrote: >> Ok. So I counter-propose that we deal with pattern bindings like this: >> >> The static semantics of a pattern binding are given by the following >> translation. A binding 'p = e' has the same meaning as the set of >> bindings >> >> z = e >> x1 = case z of { p -> x1 } >> ... >> xn = case z of { p -> xn } >> >> where z is fresh, and x1..xn are the variables of the pattern p. > > Just to check, this is saying "no change relative to Haskell 98" > (although perhaps specifying it less ambiguously), right? Right. In the absence of the MR, we need a way to say precisely what polymorphic overloaded pattern bindings mean, and the translation does just that. Cheers, Simon From marlowsd at gmail.com Tue Apr 29 17:05:58 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Apr 29 17:00:29 2008 Subject: Composition again In-Reply-To: <48160BBD.9060900@gmail.com> References: <20080415181344.GA29673@haskell.galois.com> <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> <480CFAD1.7070205@gmail.com> <48160BBD.9060900@gmail.com> Message-ID: <48178DB6.9010604@gmail.com> Simon Marlow wrote: > Simon Marlow wrote: > >> Here are the possibilities for composition: >> >> 0. do nothing >> 1. use a Unicode operator for composition >> 2. require spaces around . as an operator >> 3. require spaces around all operators >> 4. use another ASCII operator for composition, e.g. <<< >> > Ok, I'm going to try to make some progress on this. I think it's fair > to say that the only possible options are (0) do nothing, or (2) require > spaces around "." as an operator. Yesterday I talked to John Launchbury, who had previously been strongly opposed to option (0), and we noticed that the proposed change to the syntax of qualified operators actually negates some of the concerns about dot. The H98 report lists these examples: f.g f . g (three tokens) F.g F.g (qualified `g') f.. f .. (two tokens) ***** F.. F.. (qualified `.') F. F . (two tokens) that with the qualified operator change, this becomes: f.g f . g (three tokens) F.g F.g (qualified `g') f.(.) f . (.) (three tokens) ***** F.(.) F.(.) (qualified `.') F. F . (two tokens) look at the example marked with *****. With the new syntax it is no longer a weird exception: 'f..' is two tokens, whereas 'f.(.)' is three tokens just like 'f.g'. The syntax is more regular. John tells me he's happy to go with option (0) - make no other changes to dot - as long as we adopt the qualified operator change. I'm comfortable with that position too. Cheers, Simon From igloo at earth.li Tue Apr 29 17:29:04 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Apr 29 17:23:33 2008 Subject: Composition again In-Reply-To: <48178DB6.9010604@gmail.com> References: <20080416150628.GD12207@scytale.galois.com> <404396ef0804161022t4e20d8b8t8c2153ed7b28f923@mail.gmail.com> <20080418003906.GB17560@sliver.repetae.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE5239EC1@EA-EXMSG-C334.europe.corp.microsoft.com> <20080418095451.GG17560@sliver.repetae.net> <480CDF3B.1090604@gmail.com> <78A3C5650E28124399107F21A1FA41945B3336@ELON17P32002A.csfb.cs-group.com> <480CFAD1.7070205@gmail.com> <48160BBD.9060900@gmail.com> <48178DB6.9010604@gmail.com> Message-ID: <20080429212904.GA24690@matrix.chaos.earth.li> On Tue, Apr 29, 2008 at 02:05:58PM -0700, Simon Marlow wrote: > > that with the qualified operator change, this becomes: > > f.g f . g (three tokens) > F.g F.g (qualified `g') > f.(.) f . (.) (three tokens) ***** > F.(.) F.(.) (qualified `.') > F. F . (two tokens) And [f..], [F..] etc will parse as we want them to too. Sounds OK to me. Thanks Ian From ross at soi.city.ac.uk Wed Apr 30 07:18:47 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Apr 30 07:13:16 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <480F72A8.2080401@gmail.com> References: <480F72A8.2080401@gmail.com> Message-ID: <20080430111847.GA2959@soi.city.ac.uk> On Wed, Apr 23, 2008 at 10:32:24AM -0700, Simon Marlow wrote: > The current proposal on the table for what to do about the monomorphism > restriction (henceforth MR) is > > * remove the MR entirely Just to be clear, are we talking only about Rule 1 of the MR? Rule 2 seems unavoidable, but it should probably say "entire group of mutually recursive modules" rather than "entire module". From ross at soi.city.ac.uk Wed Apr 30 07:34:50 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Apr 30 07:29:18 2008 Subject: Meta-point: backward compatibility In-Reply-To: References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> Message-ID: <20080430113450.GB2959@soi.city.ac.uk> On Thu, Apr 24, 2008 at 08:18:10PM +0000, Aaron Denney wrote: > And there is a lot that clearly isn't battle tested in a reasonable new > form, though the current practice is widely agreed upon to be broken. > Examples include all monads having fail, rather than only those in a > subclass, monad not being a subclass of functor, and the whole numeric > hierarchy issue (which I don't think can be properly designed unless we > know whether it's going to be FDs or ATs, though, of course, designing > it for either would provide valuable experience for the limitations > of both), I don't think any of these need involve multi-parameter type classes (we don't need vector spaces in the Prelude), but they're often presented as use cases for things like class aliases. Even then, the numeric hierarchy is probably easier to fix that the others: one can define a finer-grain hierarchy with the existing classes as a facade, and leave clients untouched. The change would be felt by the minority defining instances of numeric classes, but they are exactly the people who find the present hierarchy inadequate. From igloo at earth.li Wed Apr 30 07:40:50 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Apr 30 07:35:17 2008 Subject: The monomorphism restriction and monomorphic pattern bindings In-Reply-To: <20080430111847.GA2959@soi.city.ac.uk> References: <480F72A8.2080401@gmail.com> <20080430111847.GA2959@soi.city.ac.uk> Message-ID: <20080430114050.GA3184@matrix.chaos.earth.li> On Wed, Apr 30, 2008 at 12:18:47PM +0100, Ross Paterson wrote: > On Wed, Apr 23, 2008 at 10:32:24AM -0700, Simon Marlow wrote: > > The current proposal on the table for what to do about the monomorphism > > restriction (henceforth MR) is > > > > * remove the MR entirely > > Just to be clear, are we talking only about Rule 1 of the MR? > > Rule 2 seems unavoidable, but it should probably say "entire group of > mutually recursive modules" rather than "entire module". Rule 2 Any monomorphic type variables that remain when type inference for an entire module is complete, are considered ambiguous, and are resolved to particular types using the defaulting rules. Sounds right to me. Although personally I think defaulting should be removed from the language (but left in the interactive environments), but that's another debate! Thanks Ian From wnoise at ofb.net Wed Apr 30 10:50:08 2008 From: wnoise at ofb.net (Aaron Denney) Date: Wed Apr 30 10:44:45 2008 Subject: Meta-point: backward compatibility References: <90889fe70804231150r25b43fe3u75b34f7faeb64b37@mail.gmail.com> <480FA85A.7000801@gmail.com> <20080430113450.GB2959@soi.city.ac.uk> Message-ID: On 2008-04-30, Ross Paterson wrote: > On Thu, Apr 24, 2008 at 08:18:10PM +0000, Aaron Denney wrote: >> And there is a lot that clearly isn't battle tested in a reasonable new >> form, though the current practice is widely agreed upon to be broken. >> Examples include all monads having fail, rather than only those in a >> subclass, monad not being a subclass of functor, and the whole numeric >> hierarchy issue (which I don't think can be properly designed unless we >> know whether it's going to be FDs or ATs, though, of course, designing >> it for either would provide valuable experience for the limitations >> of both), > > I don't think any of these need involve multi-parameter type classes > (we don't need vector spaces in the Prelude), but they're often presented > as use cases for things like class aliases. Even then, the numeric > hierarchy is probably easier to fix that the others: one can define a > finer-grain hierarchy with the existing classes as a facade, and leave > clients untouched. The change would be felt by the minority defining > instances of numeric classes, but they are exactly the people who find > the present hierarchy inadequate. Class aliases (or the ability to add superclasses) would certainly help in letting many of these things be more easily tested. I suppose we don't need vector spaces. Nor do we need rationals, complex numbers, or even arbitrarily large integers. Nevertheless, there is a huge benefit to having the interfaces for them there. -- Aaron Denney -><-