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> <