From igloo at earth.li Wed Aug 1 10:19:59 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 1 10:12:20 2007 Subject: Good Haskell Style Message-ID: <20070801141959.GA5993@matrix.chaos.earth.li> Hi all, I've been sitting on this for four months for various reasons, but Neil and Duncan keep prodding me to send it, so here it is. The numbers in the mail are probably out of date by now, due to the start of the base splitup and general development, but I'm too lazy to update them. Thanks Ian ------------------ Hi all, My last attempt to write a contentious mail was a miserable failure, so I'm giving it another go. I've written up my description and rationale for what makes good Haskell style. The full thing is at http://urchin.earth.li/~ian/style/haskell.html but I'll copy the conclusion here: * Don't leave trailing white space in your code * Don't use tabs * Aim to keep lines under 80 characters * Use the CamelCase variable naming convention * Don't use explicit braces and semicolons There are also some tips on configuring vim to help out at http://urchin.earth.li/~ian/style/vim.html I think it would be great if we could agree on this (or perhaps some other) set of style guidelines for the core libraries, and encourage their use for other libraries. Future library submissions would be required to follow the guide, and the existing codebase could either be updated as other changes are made, or en masse just before the GHC 6.8 fork (to avoid unnecessary patch merging work). Just to help motivate the "Don't use tabs" point: I think someone was saying that they thought that base should use tabs, as that is what the existing code base uses. Here are some stats which show that that doesn't seem to be the case; it's hard to draw strong conclusions without actually manually looking at a large proportion of the library, but the indication is that 4 spaces is the dominant indentation. I've attached the script that made the stats. Total files: 162 Files where some lines start tab: 121 Files where some lines start 4 spaces: 133 Files where some lines start 8 spaces: 100 Percentage files where some lines start tab: 74% Percentage files where some lines start 4 spaces: 82% Percentage files where some lines start 8 spaces: 61% Non-blank lines: 47493 Lines that start white (white lines): 20584 Lines that start tab: 4239 Lines that start 4 spaces: 10691 Lines that start 8 spaces: 4509 Percentage non-blank lines start tab: 8% Percentage non-blank lines start 4 spaces: 22% Percentage non-blank lines start 8 spaces: 9% Percentage white lines start tab: 20% Percentage white lines start 4 spaces: 51% Percentage white lines start 8 spaces: 21% And a few more stats, just for interest really: Lines that have a tab after a space: 203 Lines that have a tab after a non-white character: 2401 Percentage non-blank lines have a tab after a space: 0% Percentage non-blank lines have a tab after a non-white character: 5% Thanks Ian, Neil and Duncan -------------- next part -------------- #!/bin/bash FILES=(`find . -name "*.hs" -o -name "*.lhs" -o -name "*.hsc"`) if [ "$1" = "-v" ] then VERBOSE=1 else VERBOSE=0 fi TAB=`printf '\t'` SPACES4=" " SPACES8=" " NUM_FILES=0 FILES_SOME_LINES_START_TAB=0 FILES_SOME_LINES_START_4SPACES=0 FILES_SOME_LINES_START_8SPACES=0 for F in ${FILES[@]} do if [ "$VERBOSE" = 1 ] then echo $F fi NUM_FILES=$(($NUM_FILES + 1)) if grep -q "^$TAB" $F then FILES_SOME_LINES_START_TAB=$(($FILES_SOME_LINES_START_TAB + 1)) fi if grep -q "^$SPACES4" $F then FILES_SOME_LINES_START_4SPACES=$(($FILES_SOME_LINES_START_4SPACES + 1)) fi if grep -q "^$SPACES8" $F then FILES_SOME_LINES_START_8SPACES=$(($FILES_SOME_LINES_START_8SPACES + 1)) fi done LINES_NOT_BLANK=`grep "." ${FILES[@]} | wc -l` # LINES_START_WHITE=`grep -c "^\\($TAB\\| \\)" ${FILES[@]}` LINES_START_WHITE=`grep "^[[:space:]]" ${FILES[@]} | wc -l` LINES_START_TAB=`grep "^$TAB" ${FILES[@]} | wc -l` LINES_START_4SPACES=`grep "^$SPACES4" ${FILES[@]} | wc -l` LINES_START_8SPACES=`grep "^$SPACES8" ${FILES[@]} | wc -l` LINES_TAB_AFTER_SPACE=`grep "^[[:space:]]* $TAB" ${FILES[@]} | wc -l` LINES_TAB_AFTER_NONWHITE=`grep "^.*[^[:space:]].*$TAB" ${FILES[@]} | wc -l` echo "Total files: "\ $NUM_FILES echo "Files where some lines start tab: "\ $FILES_SOME_LINES_START_TAB echo "Files where some lines start 4 spaces: "\ $FILES_SOME_LINES_START_4SPACES echo "Files where some lines start 8 spaces: "\ $FILES_SOME_LINES_START_8SPACES echo "Percentage files where some lines start tab: "\ $((100 * $FILES_SOME_LINES_START_TAB / $NUM_FILES))% echo "Percentage files where some lines start 4 spaces: "\ $((100 * $FILES_SOME_LINES_START_4SPACES / $NUM_FILES))% echo "Percentage files where some lines start 8 spaces: "\ $((100 * $FILES_SOME_LINES_START_8SPACES / $NUM_FILES))% echo echo "Non-blank lines: "\ $LINES_NOT_BLANK echo "Lines that start white (white lines): "\ $LINES_START_WHITE echo "Lines that start tab: "\ $LINES_START_TAB echo "Lines that start 4 spaces: "\ $LINES_START_4SPACES echo "Lines that start 8 spaces: "\ $LINES_START_8SPACES echo "Percentage non-blank lines start tab: "\ $((100 * $LINES_START_TAB / $LINES_NOT_BLANK))% echo "Percentage non-blank lines start 4 spaces: "\ $((100 * $LINES_START_4SPACES / $LINES_NOT_BLANK))% echo "Percentage non-blank lines start 8 spaces: "\ $((100 * $LINES_START_8SPACES / $LINES_NOT_BLANK))% echo "Percentage white lines start tab: "\ $((100 * $LINES_START_TAB / $LINES_START_WHITE))% echo "Percentage white lines start 4 spaces: "\ $((100 * $LINES_START_4SPACES / $LINES_START_WHITE))% echo "Percentage white lines start 8 spaces: "\ $((100 * $LINES_START_8SPACES / $LINES_START_WHITE))% echo echo "Lines that have a tab after a space: "\ $LINES_TAB_AFTER_SPACE echo "Lines that have a tab after a non-white character: "\ $LINES_TAB_AFTER_NONWHITE echo "Percentage non-blank lines have a tab after a space: "\ $((100 * $LINES_TAB_AFTER_SPACE / $LINES_NOT_BLANK))% echo "Percentage non-blank lines have a tab after a non-white character: "\ $((100 * $LINES_TAB_AFTER_NONWHITE / $LINES_NOT_BLANK))% From duncan.coutts at worc.ox.ac.uk Wed Aug 1 10:50:28 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 1 10:41:40 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <1185979828.5989.69.camel@localhost> On Wed, 2007-08-01 at 15:19 +0100, Ian Lynagh wrote: > Hi all, > > I've been sitting on this for four months for various reasons, but Neil > and Duncan keep prodding me to send it, so here it is. And if we can get vague consensus we should put this guide on the haskell.org wiki. Duncan From simonmarhaskell at gmail.com Wed Aug 1 10:50:26 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Aug 1 10:42:48 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <46B09DB2.5090509@gmail.com> Ian Lynagh wrote: > * Don't leave trailing white space in your code > * Don't use tabs > * Aim to keep lines under 80 characters > * Use the CamelCase variable naming convention > * Don't use explicit braces and semicolons I'm with you all except for the 4th one: > * Use the CamelCase variable naming convention I'm rather attached to the convention I use, which is - CamelCase for exported identifiers - underscores otherwise (I'm pretty sure I don't use it consistently, so don't bother to dig up counter-examples though). Why do I like this? Ideally we'd have an IDE which would colour my exported identifiers differently, but since I don't use such an IDE the CamelCase distinction gets some of the benefit. CamelCase for exported identifiers is already an established convention (which should really be part of a library API style guide), which leaves us with underscores for local identifiers. Yes I'm aware that a single-word identifier is the same in both conventions; it's not perfect. Cheers, Simon From flippa at flippac.org Wed Aug 1 10:56:15 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Aug 1 10:48:42 2007 Subject: Good Haskell Style In-Reply-To: <46B09DB2.5090509@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> Message-ID: On Wed, 1 Aug 2007, Simon Marlow wrote: > I'm rather attached to the convention I use, which is > > - CamelCase for exported identifiers > - underscores otherwise > Yes I'm aware that a single-word identifier is the same in both conventions; > it's not perfect. > How about _nonexportedIdentifier or something similar? -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. From haskell at list.mightyreason.com Wed Aug 1 11:30:34 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Aug 1 11:23:02 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> Message-ID: <46B0A71A.2020404@list.mightyreason.com> Philippa Cowderoy wrote: > On Wed, 1 Aug 2007, Simon Marlow wrote: > >> I'm rather attached to the convention I use, which is >> >> - CamelCase for exported identifiers >> - underscores otherwise > >> Yes I'm aware that a single-word identifier is the same in both conventions; >> it's not perfect. >> > > How about _nonexportedIdentifier or something similar? > Leading underscores are used in pattern matches to indicate to GHC that unused names like '_foo' should not cause a warning to be printed. Otherwise the warning is turned off by using just '_' but that erases the readability of using an actual name. Thus: take _ [] = [] -- no warning take n [] = [] -- warning that n is unused take _n [] = [] -- no warning From seth at cql.com Wed Aug 1 11:33:06 2007 From: seth at cql.com (Seth Kurtzberg) Date: Wed Aug 1 11:25:50 2007 Subject: Good Haskell Style In-Reply-To: <46B0A71A.2020404@list.mightyreason.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> <46B0A71A.2020404@list.mightyreason.com> Message-ID: <07d601c7d451$41ba8210$c52f8630$@com> I've been using Haskell daily for a long time, and I didn't know about that underscore convention. I knew about _ being an unspecified dummy variable, but I didn't know you are allowed to follow it with a meaningful name. Guess I have some reading to do. :) -----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Chris Kuklewicz Sent: Wednesday, August 01, 2007 11:31 AM To: Philippa Cowderoy Cc: libraries@haskell.org; Simon Marlow Subject: Re: Good Haskell Style Philippa Cowderoy wrote: > On Wed, 1 Aug 2007, Simon Marlow wrote: > >> I'm rather attached to the convention I use, which is >> >> - CamelCase for exported identifiers >> - underscores otherwise > >> Yes I'm aware that a single-word identifier is the same in both conventions; >> it's not perfect. >> > > How about _nonexportedIdentifier or something similar? > Leading underscores are used in pattern matches to indicate to GHC that unused names like '_foo' should not cause a warning to be printed. Otherwise the warning is turned off by using just '_' but that erases the readability of using an actual name. Thus: take _ [] = [] -- no warning take n [] = [] -- warning that n is unused take _n [] = [] -- no warning _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries From Christian.Maeder at dfki.de Wed Aug 1 12:07:56 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Aug 1 12:00:24 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <46B0AFDC.9090301@dfki.de> Ian Lynagh wrote: > > * Don't leave trailing white space in your code > * Don't use tabs > * Aim to keep lines under 80 characters > * Use the CamelCase variable naming convention > * Don't use explicit braces and semicolons May I add: * put a final newline in your file http://haskell.org/haskellwiki/Programming_guidelines#File_Format Cheers Christian From nominolo at googlemail.com Wed Aug 1 12:28:13 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Aug 1 12:20:37 2007 Subject: Good Haskell Style In-Reply-To: <46B09DB2.5090509@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1 aug 2007, at 16.50, Simon Marlow wrote: > > * Use the CamelCase variable naming convention > > I'm rather attached to the convention I use, which is > > - CamelCase for exported identifiers > - underscores otherwise > > (I'm pretty sure I don't use it consistently, so don't bother to > dig up counter-examples though). > > Why do I like this? Ideally we'd have an IDE which would colour my > exported identifiers differently, but since I don't use such an IDE > the CamelCase distinction gets some of the benefit. CamelCase for > exported identifiers is already an established convention (which > should really be part of a library API style guide), which leaves > us with underscores for local identifiers. > > Yes I'm aware that a single-word identifier is the same in both > conventions; it's not perfect. I don't like that convention. It makes the code look really ugly. I agree, that it'd be a good idea to have a visual indication what is exported and what is not, but i'd strongly opt for something less obtrusive. In any case, though, this is something this should be done consistently or not at all; maybe we need some sort of haskell- lint? So, if leading underscores are used already, what about trailing underscores? myPublicFunction :: Foo -> Bar -> Baz myPublicFunction f b = myInternalHelperFn_ (helper_ f b) versus yPublicFunction :: Foo -> Bar -> Baz myPublicFunction f b = my_internal_helper_fn (helper f b) it's also much easier to fix when actually exporting the identifier. Just my 2 cents / Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQEVAwUBRrC0nSuNq1ISBIDTAQKHdgf/WmuXYK/Se0PSfUZ4b6g6ZyouHpzCEz47 zEyrCxxEu8zInAsY0JAF8Iyfx0C1XTDNKLvq08pZhHmBGLF3nN2e8f1fRjm24wbx UCxHK1vh8+aV5UnhS+DNoWi8kS6M5z2rezPohs3VI2H10SJKdsYYTJ3UdI+WPmlq W3Pjcd6wfAoAF+l5e/AOu1TsQi5bi5yPeMzBncxNLA+UAuyQ+ud0jf4AgtfJ6Xz4 BKjq+YYpzpY+O3/VIFz6JSsV99QRcsP69qLPDTwyhXtfTCEUawSG8XEu4K9gSMvj scWAopz9ymd8QdDt4OcvZ/qb3cr9/z1vWF38KLMv95u459fM12dvMA== =XpJV -----END PGP SIGNATURE----- From flippa at flippac.org Wed Aug 1 12:32:46 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Aug 1 12:25:07 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> Message-ID: On Wed, 1 Aug 2007, Thomas Schilling wrote: > So, if leading underscores are used already, what about trailing underscores? > I often use them where someone else would use ' as prime because my text editor's syntax highlighting is less than perfect. Also, there's an existing convention in the monad libraries using trailing underscores. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez From Malcolm.Wallace at cs.york.ac.uk Wed Aug 1 13:59:25 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 1 13:51:44 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <20070801185925.3c11436e.Malcolm.Wallace@cs.york.ac.uk> > * Don't leave trailing white space in your code > * Don't use tabs > * Aim to keep lines under 80 characters > * Use the CamelCase variable naming convention > * Don't use explicit braces and semicolons These rules seem reasonable to me, but I would finesse the second point. Whilst tabs are undesirable in code, I do often find it useful to precede _eol_ comments with tabs. "function | guard = body\t\t-- eol comment" Tabs help to align the beginning of such comments nicely; they help to avoid random misalignments due to minor editing of code; and in this location they can never change the meaning of the code. Regards, Malcolm From droundy at darcs.net Wed Aug 1 14:05:45 2007 From: droundy at darcs.net (David Roundy) Date: Wed Aug 1 13:58:07 2007 Subject: Good Haskell Style In-Reply-To: <46B09DB2.5090509@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> Message-ID: <20070801180545.GE26066@darcs.net> On Wed, Aug 01, 2007 at 03:50:26PM +0100, Simon Marlow wrote: > Ian Lynagh wrote: > > >* Don't leave trailing white space in your code > >* Don't use tabs > >* Aim to keep lines under 80 characters > >* Use the CamelCase variable naming convention > >* Don't use explicit braces and semicolons > > I'm with you all except for the 4th one: Likewise. > > * Use the CamelCase variable naming convention > > I'm rather attached to the convention I use, which is > > - CamelCase for exported identifiers > - underscores otherwise > > (I'm pretty sure I don't use it consistently, so don't bother to dig up > counter-examples though). I'm with you on this. I prefer underscores in general, and find it helpful to use them in ways distinct from CamelCase. For instance, the new "Repository" API in darcs is all CamelCase, but less portable functions (sometimes exported, but always deprecated for use in darcs commands--except in exceptions such as get) use underscores. I'd say that we ought only to have the convention that exported functions are CamelCase, and let folks do whatever they want inside a module. -- David Roundy Department of Physics Oregon State University From iavor.diatchki at gmail.com Wed Aug 1 16:06:07 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Aug 1 15:58:26 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> Hi, > * Don't leave trailing white space in your code > * Don't use tabs > * Aim to keep lines under 80 characters > * Use the CamelCase variable naming convention > * Don't use explicit braces and semicolons I like using underscores in values, and CamelCase in types---I find that the extra space makes the identifiers more readable. Despite the fact that I tend to write code that follows these conventions (except for bullet 4), I find the rules to be extremely arbitrary and I do not think that they should be given any special status. -Iavor PS: While we are discussing style, what should be the blessed amount of indentation ;-) I vote for 2 spaces. From duncan.coutts at worc.ox.ac.uk Wed Aug 1 16:22:42 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 1 16:13:53 2007 Subject: Good Haskell Style In-Reply-To: <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> Message-ID: <1185999762.5989.97.camel@localhost> On Wed, 2007-08-01 at 13:06 -0700, Iavor Diatchki wrote: > Despite the fact that I tend to write code that follows these > conventions (except for bullet 4), I find the rules to be extremely > arbitrary and I do not think that they should be given any special > status. But isn't that just the nature of a standard? A good common style helps people communicate and share their code. Of course we cannot force a style upon anyone, however many authors *want* to use a style that many other people use because it will make their code more accessible. So for their benefit we can try to elevate some common set of rules and say if you want to follow a style, follow this one. Then as a bonus the style that we pick can be somewhat less than totally arbitrary and have some practical justification like Ian's arguments about tabs and layout etc. So the value of this discussion is in trying to find a style that is sufficiently common or well justified that we can promote it as a recommended style to exiting and new coders. > PS: While we are discussing style, what should be the blessed amount > of indentation ;-) I vote for 2 spaces. So do I, but this is probably an even more contentious issue :-). Duncan From droundy at darcs.net Wed Aug 1 16:21:41 2007 From: droundy at darcs.net (David Roundy) Date: Wed Aug 1 16:14:05 2007 Subject: Good Haskell Style In-Reply-To: <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> Message-ID: <20070801202141.GF26066@darcs.net> On Wed, Aug 01, 2007 at 01:06:07PM -0700, Iavor Diatchki wrote: > Hi, > > > * Don't leave trailing white space in your code > > * Don't use tabs > > * Aim to keep lines under 80 characters > > * Use the CamelCase variable naming convention > > * Don't use explicit braces and semicolons > > I like using underscores in values, and CamelCase in types---I find > that the extra space makes the identifiers more readable. Despite the > fact that I tend to write code that follows these conventions (except > for bullet 4), I find the rules to be extremely arbitrary and I do not > think that they should be given any special status. The use of tabs can easily make code unreadable on other developers' editors. It's a bad idea, not an arbitrary convention. Keeping the line width down is useful for making code readable on folks with smaller monitors or larger fonts. And note that it says "Aim", which means that if it impairs readability in the judgement of the developer, it's not a violation. Trailing white space doesn't particularly hurt, except if you're using version control, in which case any removal of white space is liable to conflict with actual coding changes, so it's better to have a policy that it shouldn't be included. I've certainly never heard of a scenario in which trailing white space is beneficial. The last one "Don't use explicit braces and semicolons" does seem a bit arbitrary and heavy-handed. I'd rather not use them myself, but wouldn't complain of a developer who does so. > PS: While we are discussing style, what should be the blessed amount > of indentation ;-) I vote for 2 spaces. That's certainly something that shouldn't be in a coding guide. -- David Roundy Department of Physics Oregon State University From nominolo at googlemail.com Wed Aug 1 17:33:40 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Aug 1 17:26:04 2007 Subject: Good Haskell Style In-Reply-To: <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> Message-ID: On 1 aug 2007, at 22.06, Iavor Diatchki wrote: > Hi, > >> * Don't leave trailing white space in your code >> * Don't use tabs >> * Aim to keep lines under 80 characters >> * Use the CamelCase variable naming convention >> * Don't use explicit braces and semicolons > > I like using underscores in values, and CamelCase in types---I find > that the extra space makes the identifiers more readable. Despite the > fact that I tend to write code that follows these conventions (except > for bullet 4), I find the rules to be extremely arbitrary and I do not > think that they should be given any special status. Style rules will *always* be arbitrary. The sole point is to have *consistency*. You can always argue against decisions, there will hardly be any waterproof arguments (or rather Coq-proofed or sth.), but consistency is important and is absolutely appropriate for the libraries. This is not to say that this should be a the style for all Haskell programs written anywhere, but it would be good to have a normative style for the central libraries. Others then might adopt parts of this guide for their projects, or not. I am also pro enforced white space between binary operators (ie, "foo ++ bar" and "42 + 6 ^ (-5)" rather than "foo++bar" and "42+6^(-5)") and defined module orderings (ie, local first, external later, or the other way round.) In any case, stylistic standards are there to make the boring things easy to recognize (and hence ignore) and let you focus on the real meat. / Thomas From nominolo at googlemail.com Wed Aug 1 17:49:54 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Aug 1 17:42:17 2007 Subject: Good Haskell Style In-Reply-To: <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> Message-ID: Oh, and while we're at arbitrary style rules, I have one more (with a reason though, to do so). I find this way of indenting "where" really annoying: fun :: Yawn -> Moo a -> Meep a fun y x = do unMoo x blah return it where blah = foo 42 it = blax &&& meee . y it should rather be fun :: Yawn -> Moo a -> Meep a fun y x = do unMoo x blah return it where blah = foo 42 it = blax &&& meee . y Even if the "where" is syntax-highlighted, it is still very hard to parse visually. In a completely unrelated issue, I think this is a very useful way to indent code: foo x y z = case x of Blab a b c -> ... Blib d e f g -> ... _ -> ... It helps avoiding parentheses and reduces line length (especially for longer function names). Compare this with: foo (Blab a b c) y z = ... foo (Blib d e f g) y z = ... foo x y z = ... / Thomas From isaacdupree at charter.net Wed Aug 1 19:28:08 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Aug 1 19:28:17 2007 Subject: [Haskell-cafe] RE: Definition of the Haskell standard library In-Reply-To: References: <1185812841.5721.90.camel@localhost> <1185887417.5989.24.camel@localhost> Message-ID: <46B11708.50200@charter.net> Simon Peyton-Jones wrote: > When you install packages A,B,C, the documentation for A,B,C (and nothing > else) ought to be locally available as an integrated whole, much as at > the GHC web site. I don't know whether Cabal does, or could do, that, > but it's surely what one would expect. and would take some educating of users, like me who tend to use online resources even when there are equivalent local files available. Maybe mentioning it in the User's Guide or somewhere on the website would be enough. Actually sometimes I user-install library packages, not for the whole system; then should there be an integrated whole anywhere? Isaac From isaacdupree at charter.net Wed Aug 1 19:50:53 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Aug 1 19:50:59 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <46B11C5D.9070702@charter.net> Ian Lynagh wrote: > * Don't leave trailing white space in your code > * Don't use tabs > * Aim to keep lines under 80 characters > * Use the CamelCase variable naming convention Agreed. And newline at end of file. And prefer to indent an even number (normally an even number of spaces, but, an odd number when using birdtrack-literate-haskell '> foo = ...'). I am often quite arbitrary about anything more strictured than this, and prefer to lay it out depending on what seems most clear in the surrounding code (which, admittedly, usually assumes a monospace font). > * Don't use explicit braces and semicolons Sometimes I use explicit semicolons, and even sometimes braces to make the bracketing more clear, when there are a lot of small cases, for example. But usually layout is better. A separate rule which I do try to stick to is, * don't depend on the width of non-space characters for layout : " \(let\|where\|do\|of\)[ ] such that the layout following them extends onto another line "; however this is a nuisance to check manually, (is more complicated when tabs are allowed), and GHC doesn't have a warning flag for it. Isaac From john at repetae.net Wed Aug 1 20:10:27 2007 From: john at repetae.net (John Meacham) Date: Wed Aug 1 20:02:48 2007 Subject: Good Haskell Style In-Reply-To: <46B09DB2.5090509@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <46B09DB2.5090509@gmail.com> Message-ID: <20070802001027.GA30892@momenergy.repetae.net> On Wed, Aug 01, 2007 at 03:50:26PM +0100, Simon Marlow wrote: > Ian Lynagh wrote: > > >* Don't leave trailing white space in your code > >* Don't use tabs > >* Aim to keep lines under 80 characters > >* Use the CamelCase variable naming convention > >* Don't use explicit braces and semicolons > > I'm with you all except for the 4th one: > > > * Use the CamelCase variable naming convention > > I'm rather attached to the convention I use, which is > > - CamelCase for exported identifiers > - underscores otherwise > > (I'm pretty sure I don't use it consistently, so don't bother to dig up > counter-examples though). I almost do this, I use underscores for CAFs and very simple names (often one word) for non-exported functions, but I try to keep them local, in where or let clauses rather than at the top level. non-exported top-level functions just are not all that common. In any case, I was never a fan of style guidelines. well, not entirely true, I am very much in favor of people publishing their guidelines to give others inspiration and to learn from like Ian did. I was never in favor of trying to get people to come to a consensus on one, many man-hours that could have been spent writing delicious code has been whittled away in pursuit of conformity for conformities sake. Though, there certainly are technical (rather than aesthetic) reasons for a lot of these things that some might consider style, such as the whitespace ones above and indentation patterns that allow easy editing. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Thu Aug 2 03:50:40 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 2 03:43:04 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: | * Don't use tabs Is there an emacs mode or Lisp-blob that lets you use TAB to go to the next n-col boundary, but expands the jump into spaces. In emacs modes, TAB usually does all sorts of other snazzy things concerning layout, which I don't want. I just want something that behaves like old-fashioned TAB, but generates a file with spaces. Simon From Alistair_Bayley at invescoperpetual.co.uk Thu Aug 2 03:51:01 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Thu Aug 2 03:43:19 2007 Subject: Good Haskell Style In-Reply-To: <46B11C5D.9070702@charter.net> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> > From: libraries-bounces@haskell.org > [mailto:libraries-bounces@haskell.org] On Behalf Of Isaac Dupree > > And prefer to indent an even number (normally an even number > of spaces, > but, an odd number when using birdtrack-literate-haskell '> > foo = ...'). I moot that birdtrack-literate-haskell should be avoided, largely because (AFAICT) it is not supported by Haddock. Section 2.1 in the Haddock manual suggests that you can preprocess the .lhs source to make it palatable: http://www.haskell.org/haddock/haddock-html-0.8/invoking.html#cpp by saying (for example): ghc -E Main.lhs -o Main.hs However, this appears to discard all lines which do not start with >, which includes many comments (like the module header), which is not much use to Haddock. Currently, for many of Takusen's source files I run them through a custom preprocessor which converts them to regular .hs files, preserving all comments, and then feed these to Haddock. That's not to say that the birdtrack style is not useful; it's great for Oleg's expositional email-as-literate-source postings. However, having used it extensively in Takusen, I'm of the opinion that we should have started with regular .hs source. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From nominolo at googlemail.com Thu Aug 2 05:23:52 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Aug 2 05:16:14 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> On 2 aug 2007, at 09.50, Simon Peyton-Jones wrote: > Is there an emacs mode or Lisp-blob that lets you use TAB to go to > the next n-col boundary, but expands the jump into spaces. > > In emacs modes, TAB usually does all sorts of other snazzy things > concerning layout, which I don't want. I just want something that > behaves like old-fashioned TAB, but generates a file with spaces. This should work: ;; tabs are evil, always use spaces instead (setq indent-tabs-mode nil) ;; in your haskell-mode-hook: (define-key haskell-mode-map [tab] 'indent-for-tab-command) Regards, / Thomas From simonmarhaskell at gmail.com Thu Aug 2 06:10:22 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Aug 2 06:02:44 2007 Subject: Good Haskell Style In-Reply-To: <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> Message-ID: <46B1AD8E.1020007@gmail.com> Thomas Schilling wrote: > On 2 aug 2007, at 09.50, Simon Peyton-Jones wrote: >> Is there an emacs mode or Lisp-blob that lets you use TAB to go to the >> next n-col boundary, but expands the jump into spaces. >> >> In emacs modes, TAB usually does all sorts of other snazzy things >> concerning layout, which I don't want. I just want something that >> behaves like old-fashioned TAB, but generates a file with spaces. > > This should work: > > ;; tabs are evil, always use spaces instead > (setq indent-tabs-mode nil) > > ;; in your haskell-mode-hook: > (define-key haskell-mode-map [tab] 'indent-for-tab-command) While we're on emacs... I know I can colour trailing whitespace differently, but that's just annoying. What I want is: on lines that I edit, remove the trailing whitespace (and if I undo the edit, put the whitespace back too). Is there something that does that? I couldn't find it. Cheers, Simon From jon.fairbairn at cl.cam.ac.uk Thu Aug 2 06:48:37 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Aug 2 06:41:16 2007 Subject: Good Haskell Style References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: David Roundy writes: > Trailing white space doesn't particularly hurt, except if you're using > version control, in which case any removal of white space is liable to > conflict with actual coding changes, so it's better to have a policy that > it shouldn't be included. This is surely an issue with either the language definition or the version control system. In general, we ought to aim for a state of affairs where every requirement we make is mechannically checked. In this particular case, I'd say that the version control system ought to be more syntactically aware when looking for differences?, for example by removing all trailing space before doing comparisons (and making sure that anything extracted from the repo has none). > I've certainly never heard of a scenario in which > trailing white space is beneficial. Neither have I, but since it's invisible, asking that it not be there without providing automatic mechanical assistance is to add a tedious burden. [1] this isn't the only place where a version control system that understood more of the language would be useful: for example, rather than having to specify a regexp, I'd like darcs replace to pick one (from a configuration file?) depending on language. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From duncan.coutts at worc.ox.ac.uk Thu Aug 2 08:39:48 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 2 08:30:57 2007 Subject: Good Haskell Style In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> Message-ID: <1186058388.5989.169.camel@localhost> On Thu, 2007-08-02 at 08:51 +0100, Bayley, Alistair wrote: > > From: libraries-bounces@haskell.org > > [mailto:libraries-bounces@haskell.org] On Behalf Of Isaac Dupree > > > > And prefer to indent an even number (normally an even number > > of spaces, > > but, an odd number when using birdtrack-literate-haskell '> > > foo = ...'). > > I moot that birdtrack-literate-haskell should be avoided, largely > because (AFAICT) it is not supported by Haddock. Doesn't Cabal handle this transparently? I thought it did. If you find it doesn't please file a bug against Cabal. Duncan From alistair at abayley.org Thu Aug 2 08:56:34 2007 From: alistair at abayley.org (Alistair Bayley) Date: Thu Aug 2 08:48:50 2007 Subject: Good Haskell Style In-Reply-To: <1186058388.5989.169.camel@localhost> References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> Message-ID: <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> > > I moot that birdtrack-literate-haskell should be avoided, largely > > because (AFAICT) it is not supported by Haddock. > > Doesn't Cabal handle this transparently? I thought it did. If you find > it doesn't please file a bug against Cabal. > > Duncan I didn't think it would work, because presumably it just invokes Haddock anyway. So I just tried it, and got: dist\build\tmp\Database\Enumerator.hs:"dist\\build\\tmp\\Database\\Enumerator.hs": 187:1: Parse error and the offending lines in this file are: #ifndef __HADDOCK__ deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess) #else -- Haddock can't cope with the "MonadReader sess" instance deriving (Functor, Monad, MonadIO, MonadFix) #endif so it would appear that __HADDOCK__ is not defined. But there's a bigger problem, in that this Enumerator.hs file is obviously the output of "ghc -E Enumerator.lhs -o Enumerator.hs", as it does not contain any of the original comments, which again is no good for Haddock. Am I using birdtrack-lhs the wrong way? I've written my Haddock comments like so: | Returns the number of rows affected. > execDML :: IE.Command stmt s => stmt -> DBM mark s Int and: | Module : Database.Enumerator Copyright : (c) 2004 Oleg Kiselyov, Alistair Bayley License : BSD-style ... But now I'm thinking that perhaps I should have written: > --| Returns the number of rows affected. > execDML :: IE.Command stmt s => stmt -> DBM mark s Int which kinda defeats the purpose of the birdtrack style.IMO. Alistair From alistair at abayley.org Thu Aug 2 08:58:09 2007 From: alistair at abayley.org (Alistair Bayley) Date: Thu Aug 2 08:50:25 2007 Subject: Good Haskell Style In-Reply-To: <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> Message-ID: <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> > and the offending lines in this file are: > > #ifndef __HADDOCK__ > deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess) > #else > -- Haddock can't cope with the "MonadReader sess" instance > deriving (Functor, Monad, MonadIO, MonadFix) > #endif > > so it would appear that __HADDOCK__ is not defined. Sorry, I should have said, "so it appears that -cpp is not being used". Alistair From nominolo at googlemail.com Thu Aug 2 09:12:05 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Aug 2 09:04:32 2007 Subject: Good Haskell Style In-Reply-To: <46B1AD8E.1020007@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> Message-ID: <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> On 2 aug 2007, at 12.10, Simon Marlow wrote: > While we're on emacs... I know I can colour trailing whitespace > differently, but that's just annoying. What I want is: on lines > that I edit, remove the trailing whitespace (and if I undo the > edit, put the whitespace back too). Is there something that does > that? I couldn't find it. The simplest thing I can think of, is to not remove whitespace at all, but to only remove it when you're saving the file. I know that some modes use such a save hook. It also wouldn't modify the actual file (ie, don't remove the whitespace until you save the file for the first time), as long as you edit it. The only time the spaces would be removed permanently were if you save the file, close the buffer, and then re-open the file. If I can come up with a simple solution, I'll let you know. / Thomas From duncan.coutts at worc.ox.ac.uk Thu Aug 2 09:18:58 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 2 09:10:09 2007 Subject: Good Haskell Style In-Reply-To: <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> Message-ID: <1186060739.5989.179.camel@localhost> On Thu, 2007-08-02 at 13:58 +0100, Alistair Bayley wrote: > > and the offending lines in this file are: > > > > #ifndef __HADDOCK__ > > deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess) > > #else > > -- Haddock can't cope with the "MonadReader sess" instance > > deriving (Functor, Monad, MonadIO, MonadFix) > > #endif > > > > so it would appear that __HADDOCK__ is not defined. > > Sorry, I should have said, "so it appears that -cpp is not being used". It uses -cpp if CPP is in the language extensions in the .cabal file. (At least that's what the code says it's supposed to be doing which is not a guarantee that it works). It does also define __HADDOCK__ when it uses cpp. Hmm, actually there is a problem here. Unlitting does indeed remove all the literate comments, so haddock will never see any markup that is put in the non-code part. To work with current haddock it'd have to be: > -- | This is a haddock comment > foo = ... because that's the only code haddock will see since unlitting turns a literate haskell file into a valid .hs file. It's a purely textual transformation and it's done by removing all the non > lines. Perhaps unlitting should be done by converting all literate comments into {- ... -} style comments. Then it'd probably work with haddock like you have it now: | haddock comment > foo = ... since that'd become: {- | haddock comment -} foo = ... Or something like that. Perhaps that's worth investigating and adding to ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting. Duncan From alistair at abayley.org Thu Aug 2 09:45:26 2007 From: alistair at abayley.org (Alistair Bayley) Date: Thu Aug 2 09:37:44 2007 Subject: Good Haskell Style In-Reply-To: <1186060739.5989.179.camel@localhost> References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> Message-ID: <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> > It uses -cpp if CPP is in the language extensions in the .cabal file. So it does. So now Haddock completes, but produces very limited output. > Perhaps unlitting should be done by converting all literate comments > into {- ... -} style comments. > > Or something like that. Perhaps that's worth investigating and adding to > ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting. As I alluded to earlier, I have a program which I wrote to do this. It prefixes "--" rather than enclosing in {- -}, and it's not perfect (there are a number of cases it doesn't handle, although I'm of the opinion that you shouldn't be doing whatever it fails on). I'm thinking it might be feasible to distribute this in the Takusen release and hook it into the cabal "setup haddock" command to preprocess the .lhs files. I have been tempted to run it over our .lhs once and for all, and convert everything to regular .hs files, but Oleg seems to like the birdtrack style, so we've decided to stick with it for now. Alistair From jon.fairbairn at cl.cam.ac.uk Thu Aug 2 10:41:39 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Aug 2 10:34:15 2007 Subject: Good Haskell Style References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> Message-ID: "Alistair Bayley" writes: > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > So it does. So now Haddock completes, but produces very limited output. > > > Perhaps unlitting should be done by converting all literate comments > > into {- ... -} style comments. I have a programme (FishFeeder) that does this; it's a bit hacky, but I could post it here if someone was interested in taking it on. > As I alluded to earlier, I have a program which I wrote to do this. It > prefixes "--" rather than enclosing in {- -}, Mine uses {- -} and escapes any such present in comments. Here is the first comment from the source, which is itself literate haddock: | Preprocess literate haskell with Haddockumentation in the literate comments for use with Haddock. So making things a bit prettier Assumes that there is at least one space after every \">\", and indents the \"{-\"s (but not the \"-}\"s) by that much so that Haddock doesn't give a parse error. This is a bit of a hack, but I reckon it's haddock's fault since comments shouldn't have any effect on layout. > and it's not perfect I'd very be surprised if mine were! > (there are a number of cases it doesn't handle, although I'm of the > opinion that you shouldn't be doing whatever it fails on). I'm > thinking it might be feasible to distribute this in the Takusen > release and hook it into the cabal "setup haddock" command to > preprocess the .lhs files. It would surely be better to distribute a tool (either with compilers or with haddock) so that it worked for anyone who likes literate haskell? > I have been tempted to run it over our .lhs once and for all, and > convert everything to regular .hs files, but Oleg seems to like the > birdtrack style, so we've decided to stick with it for now. I much prefer the birdtrack style; it's a matter of taste, and there's nothing more likely to cause disaffection than insisting that someone abide by someone else's taste. I would hate to see it deprecated just because the tools were no good. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From kahl at cas.mcmaster.ca Thu Aug 2 11:24:15 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Thu Aug 2 11:18:24 2007 Subject: Good Haskell Style In-Reply-To: (message from Jon Fairbairn on 02 Aug 2007 11:48:37 +0100) References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: <20070802152415.26682.qmail@schroeder.cas.mcmaster.ca> David Roundy wrote: > I've certainly never heard of a scenario in which > trailing white space is beneficial. I have seen ``\ '' at the end of line in TeX, and consider it extremely bad practice. Just something to keep in mind in this context... Wolfram From duncan.coutts at worc.ox.ac.uk Thu Aug 2 11:32:48 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 2 11:23:58 2007 Subject: Good Haskell Style In-Reply-To: References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> Message-ID: <1186068768.5989.185.camel@localhost> On Thu, 2007-08-02 at 15:41 +0100, Jon Fairbairn wrote: > "Alistair Bayley" writes: > > > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > > > So it does. So now Haddock completes, but produces very limited output. > > > > > Perhaps unlitting should be done by converting all literate comments > > > into {- ... -} style comments. > > I have a programme (FishFeeder) that does this; it's a bit > hacky, but I could post it here if someone was interested in > taking it on. Sure why not. Post it. As I say, we've already got unlit code in Cabal. If anyone wants to then make a patch to Cabal's unlit code that'd be much appreciated. Then we can ask Alistair to use Takusen as a test case. Or we could see about getting it into cpphs's --unlit mode. Duncan From jon.fairbairn at cl.cam.ac.uk Thu Aug 2 11:40:26 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Aug 2 11:32:58 2007 Subject: Good Haskell Style References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> <1186068768.5989.185.camel@localhost> Message-ID: Duncan Coutts writes: > On Thu, 2007-08-02 at 15:41 +0100, Jon Fairbairn wrote: > > "Alistair Bayley" writes: > > > > > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > > > > > So it does. So now Haddock completes, but produces very limited output. > > > > > > > Perhaps unlitting should be done by converting all literate comments > > > > into {- ... -} style comments. > > > > I have a programme (FishFeeder) that does this; it's a bit > > hacky, but I could post it here if someone was interested in > > taking it on. > > Sure why not. Post it. As I say, we've already got unlit code in Cabal. OK, but as I said, it's hacky... -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.lhs Type: application/haskell Size: 2832 bytes Desc: FishFeeder/Main.lhs Url : http://www.haskell.org/pipermail/libraries/attachments/20070802/1564f5e3/Main.bin -------------- next part -------------- -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From haskell2 at davidb.org Thu Aug 2 12:03:56 2007 From: haskell2 at davidb.org (David Brown) Date: Thu Aug 2 11:56:16 2007 Subject: Good Haskell Style In-Reply-To: <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> Message-ID: <46B2006C.6030000@davidb.org> Thomas Schilling wrote: > The simplest thing I can think of, is to not remove whitespace at > all, but to only remove it when you're saving the file. I know that > some modes use such a save hook. It also wouldn't modify the actual > file (ie, don't remove the whitespace until you save the file for > the first time), as long as you edit it. The only time the spaces > would be removed permanently were if you save the file, close the > buffer, and then re-open the file. Picture mode removes trailing space when you exit it, so perhaps the function that does that is available to call upon saving. Dave From nominolo at googlemail.com Thu Aug 2 12:16:25 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Aug 2 12:08:47 2007 Subject: Good Haskell Style In-Reply-To: <46B2006C.6030000@davidb.org> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> <46B2006C.6030000@davidb.org> Message-ID: <8962BD11-B6CE-46D1-9815-ED78C73B0D7C@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2 aug 2007, at 18.03, David Brown wrote: > Thomas Schilling wrote: > >> The simplest thing I can think of, is to not remove whitespace at >> all, but to only remove it when you're saving the file. I know that >> some modes use such a save hook. It also wouldn't modify the actual >> file (ie, don't remove the whitespace until you save the file for >> the first time), as long as you edit it. The only time the spaces >> would be removed permanently were if you save the file, close the >> buffer, and then re-open the file. > > Picture mode removes trailing space when you exit it, so perhaps the > function that does that is available to call upon saving. > > Dave > Well, this works: (defun delete-trailing-space () "Deletes trailing space from all lines in buffer." (interactive) (or buffer-read-only (save-excursion (message "Deleting trailing spaces ... ") (goto-char (point-min)) (while (< (point) (point-max)) (end-of-line nil) (delete-horizontal-space) (forward-line 1)) (message "Deleting trailing spaces ... done."))) nil) ; indicates buffer-not-saved for write-file-hook (add-hook 'haskell-mode-hook 'my-haskell-mode-hook) ;; Make the hook a named function, so we can redefine it :: without having torestart emacs. (defun my-haskell-mode-hook () ... (add-hook 'write-file-hooks 'delete-trailing-space) ... )) But it has the problem that it will delete the whitespace also in the open buffer, so you have to re-insert the whitespace at the end of the line. I am just looking at how to modify the editing functions, to have this work more seamlessly. / Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQEVAwUBRrIDWiuNq1ISBIDTAQKE5wf/dSuD8pAIaaUj/R4qqB022Z0hfhLjxZpc 2oLNjYCWwYKbPu7NUOuQZ5KasP6A8yJstqZndpcllxNHimKAuqJ6CSGcEEswfpVL LX5yz9YctFvABXSF0n7zITaQACkkTSHiFPpv/7B6h6mUZYNq8aTpW+PjxGTWn1g3 r2aE5ihhMJZwH/ted+jvjWibf1tP8CtHXSQkzyJpDRGdVcpKogwoJ0HLdL/pA4Kg +Nc0rAST/zPGPIJPXsUq4LHyH5kMQcLrgtukwN43ijqOv1sGR4Yh6hlapi82nZ0i J0avFsi/6TibwrMgearo/WqU8gbrD4Nefl191vCmyWv5JUSAt/H6Gw== =/gC3 -----END PGP SIGNATURE----- From droundy at darcs.net Thu Aug 2 13:17:02 2007 From: droundy at darcs.net (David Roundy) Date: Thu Aug 2 13:09:21 2007 Subject: Good Haskell Style In-Reply-To: <46B1AD8E.1020007@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> Message-ID: <20070802171700.GC26066@darcs.net> On Thu, Aug 02, 2007 at 11:10:22AM +0100, Simon Marlow wrote: > Thomas Schilling wrote: > >On 2 aug 2007, at 09.50, Simon Peyton-Jones wrote: > >>Is there an emacs mode or Lisp-blob that lets you use TAB to go to the > >>next n-col boundary, but expands the jump into spaces. > >> > >>In emacs modes, TAB usually does all sorts of other snazzy things > >>concerning layout, which I don't want. I just want something that > >>behaves like old-fashioned TAB, but generates a file with spaces. > > > >This should work: > > > >;; tabs are evil, always use spaces instead > >(setq indent-tabs-mode nil) > > > >;; in your haskell-mode-hook: > > (define-key haskell-mode-map [tab] 'indent-for-tab-command) > > While we're on emacs... I know I can colour trailing whitespace > differently, but that's just annoying. What I want is: on lines that I > edit, remove the trailing whitespace (and if I undo the edit, put the > whitespace back too). Is there something that does that? I couldn't find > it. This ought to be doable with a --prehook in darcs record, except that darcs doesn't yet support prehooks. It's nicer if done by the editor, though. -- David Roundy Department of Physics Oregon State University From droundy at darcs.net Thu Aug 2 13:19:29 2007 From: droundy at darcs.net (David Roundy) Date: Thu Aug 2 13:11:49 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: <20070802171929.GD26066@darcs.net> On Thu, Aug 02, 2007 at 11:48:37AM +0100, Jon Fairbairn wrote: > [1] this isn't the only place where a version control system > that understood more of the language would be useful: for > example, rather than having to specify a regexp, I'd like > darcs replace to pick one (from a configuration file?) > depending on language. This latter bit is pretty easily added, but I doubt many people have repositories in which they use darcs replace often on multiple languages, so it seems like it ought to be pretty low-priority. -- David Roundy Department of Physics Oregon State University From ashley at semantic.org Thu Aug 2 21:52:01 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Aug 2 21:44:40 2007 Subject: Good Haskell Style In-Reply-To: <20070801141959.GA5993@matrix.chaos.earth.li> References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: Ian Lynagh wrote: > * Don't leave trailing white space in your code > * Don't use tabs > * Aim to keep lines under 80 characters > * Use the CamelCase variable naming convention > * Don't use explicit braces and semicolons "by giving a parse error if we break any of its rules" -- well, you hope, right? My own preferences: * Don't leave trailing white space in your code. * Use one tab to indent each level. Display them at 4 space boundaries. * Aim to keep lines under about 150 characters. * Use the CamelCase variable naming convention. * Use explicit braces and semicolons. Use "Allman" style. * Put a newline at the end of the file. * Prefix constructor names with "Mk" if there's only one in the type. * Move private definitions to other "where" clauses where possible. * Never use any unsafe functions (besides FFI). This is Haskell. * Compile with "-Wall -Werror". This implies lots of type signatures. For the time library source however I was rather closer to Ian's guidelines, just so as not to annoy people. I think it still has tabs though. -- Ashley Yakeley From simonmarhaskell at gmail.com Fri Aug 3 04:07:35 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Aug 3 03:59:51 2007 Subject: Good Haskell Style In-Reply-To: <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> Message-ID: <46B2E247.8040807@gmail.com> Thomas Schilling wrote: > > On 2 aug 2007, at 12.10, Simon Marlow wrote: >> While we're on emacs... I know I can colour trailing whitespace >> differently, but that's just annoying. What I want is: on lines that >> I edit, remove the trailing whitespace (and if I undo the edit, put >> the whitespace back too). Is there something that does that? I >> couldn't find it. > > The simplest thing I can think of, is to not remove whitespace at all, > but to only remove it when you're saving the file. I know that some > modes use such a save hook. It also wouldn't modify the actual file > (ie, don't remove the whitespace until you save the file for the first > time), as long as you edit it. The only time the spaces would be > removed permanently were if you save the file, close the buffer, and > then re-open the file. > > If I can come up with a simple solution, I'll let you know. I don't actually want it done on the whole file, which is why I asked for the behaviour only on lines that I edit. The idea is to be revision-control-friendly by not introducing unrelated formatting changes. You could start by removing all the trailing whitespace in all the sources in the repository, but I think that's unnecessary. Also I don't want to be forced to do this everywhere. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Fri Aug 3 08:48:23 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 3 08:39:29 2007 Subject: Good Haskell Style In-Reply-To: <46B2E247.8040807@gmail.com> References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> <46B2E247.8040807@gmail.com> Message-ID: <1186145303.5989.212.camel@localhost> On Fri, 2007-08-03 at 09:07 +0100, Simon Marlow wrote: > I don't actually want it done on the whole file, which is why I asked for > the behaviour only on lines that I edit. The idea is to be > revision-control-friendly by not introducing unrelated formatting changes. Ah, but actually it's even harder than that. You want to strip only lines that end up in the final diff, not merely ones that you edit (but may end up leaving the same). So actually perhaps it can be done on save by diffing the old saved version against the to-be-saved version and fixing the white space in those new lines that end up covered by the diff. Sounds like a task for Yi's Haskell mode, all it needs to do is import the darcs diff code... :-) Duncan From benjamin.franksen at bessy.de Fri Aug 3 09:30:46 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Fri Aug 3 09:23:13 2007 Subject: Good Haskell Style References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: Jon Fairbairn wrote: > David Roundy writes: >> Trailing white space doesn't particularly hurt, except if you're using >> version control, in which case any removal of white space is liable to >> conflict with actual coding changes, so it's better to have a policy that >> it shouldn't be included. > > This is surely an issue with either the language definition > or the version control system. In general, we ought to aim > for a state of affairs where every requirement we make is > mechannically checked. In this particular case, I'd say that > the version control system ought to be more syntactically > aware when looking for differences?, for example by removing > all trailing space before doing comparisons (and making sure > that anything extracted from the repo has none). > >> I've certainly never heard of a scenario in which >> trailing white space is beneficial. > > Neither have I, but since it's invisible, asking that it not > be there without providing automatic mechanical assistance > is to add a tedious burden. sed -e 's/[ \t]+$//' Cheers Ben From jon.fairbairn at cl.cam.ac.uk Fri Aug 3 10:38:04 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Fri Aug 3 10:30:41 2007 Subject: Good Haskell Style References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: Benjamin Franksen writes: > Jon Fairbairn wrote: > > David Roundy writes: > >> I've certainly never heard of a scenario in which > >> trailing white space is beneficial. > > > > Neither have I, but since it's invisible, asking that it not > > be there without providing automatic mechanical assistance > > is to add a tedious burden. > > sed -e 's/[ \t]+$//' Not the whole story, surely; you must want me to do something like create sort-it: #!/bin/bash find /home/jf -name \*.hs -o -name \*.lhs | xargs -IX sed -i.bak -e 's/[ \t]+$//' X and put it in a my crontab to run once a day? Otherwise it's not automatic. Only, strangely enough, what you wrote doesn't work (s/-e/-r/). -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Fri Aug 3 10:45:11 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Fri Aug 3 10:37:44 2007 Subject: Good Haskell Style References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> <20070802171929.GD26066@darcs.net> Message-ID: David Roundy writes: > On Thu, Aug 02, 2007 at 11:48:37AM +0100, Jon Fairbairn wrote: > > [1] this isn't the only place where a version control system > > that understood more of the language would be useful: for > > example, rather than having to specify a regexp, I'd like > > darcs replace to pick one (from a configuration file?) > > depending on language. > > This latter bit is pretty easily added, but I doubt many people have > repositories in which they use darcs replace often on multiple languages, > so it seems like it ought to be pretty low-priority. I wasn't particularly thinking of multiple languages. The default is wrong for Haskell, for example, so I have to put something in _darcs/prefs/defaults. Surely it would be better to do that once and for all? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From benjamin.franksen at bessy.de Fri Aug 3 13:32:40 2007 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Fri Aug 3 13:25:14 2007 Subject: Good Haskell Style References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: Jon Fairbairn wrote: > Benjamin Franksen writes: >> Jon Fairbairn wrote: >> > David Roundy writes: >> >> I've certainly never heard of a scenario in which >> >> trailing white space is beneficial. >> > >> > Neither have I, but since it's invisible, asking that it not >> > be there without providing automatic mechanical assistance >> > is to add a tedious burden. >> >> sed -e 's/[ \t]+$//' > > Not the whole story, surely; No, of course not. > you must want me to do I don't want you to do anything at all. I merely wanted to illustrate that getting rid of trailing whitespace is easily automated. Well, let's say half-automated: you still need to push the button. > something like create sort-it: > > #!/bin/bash > find /home/jf -name \*.hs -o -name \*.lhs | xargs -IX sed -i.bak -e 's/[ \t]+$//' X > > and put it in a my crontab to run once a day? Otherwise it's > not automatic. No crontab entry needed here (wouldn't help, by the way, since you probably want to record on the same day you wrote something). Also not necessary to recurse over whole home directory. It needs to be done only right before darcs-record-ing changes and only for the standard libraries. As has been noted by someone else, darcs even helps you by highlighting trailing whitespace in hunks, in case you forgot to run your script over the source files. I agree that a darcs prehook (if they existed) would be an even nicer solution. > Only, strangely enough, what you wrote > doesn't work (s/-e/-r/). Sorry, I didn't test the code. Forgot to add the usual disclaimer... ;-) (Always bugs me that sed and grep have these half-regexes as default.) Cheers Ben From droundy at darcs.net Fri Aug 3 14:57:07 2007 From: droundy at darcs.net (David Roundy) Date: Fri Aug 3 14:49:21 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> Message-ID: <20070803185707.GI20161@darcs.net> On Thu, Aug 02, 2007 at 06:52:01PM -0700, Ashley Yakeley wrote: > Ian Lynagh wrote: > > >* Don't leave trailing white space in your code > >* Don't use tabs > >* Aim to keep lines under 80 characters > >* Use the CamelCase variable naming convention > >* Don't use explicit braces and semicolons > > "by giving a parse error if we break any of its rules" -- well, you > hope, right? > > My own preferences: ... > * Use one tab to indent each level. Display them at 4 space boundaries. But this means that your code will have the possibility of layout bugs that not visible to the programmer, since according to the report a tab corresponds to eight spaces. Sounds like the worst of all possible worlds. -- David Roundy Department of Physics Oregon State University From simonpj at microsoft.com Fri Aug 3 15:34:07 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Aug 3 15:26:23 2007 Subject: Cabal bug Message-ID: I have not been following the recent work on Cabal, but I tried to build in the gap before this patch was committed. I Fri Aug 3 18:57:01 GMT Daylight Time 2007 Thomas Schilling * Fix tab in Cabal.cabal. I was surprised to find that tabs are disallowed in cabal files. Is that really the intention? It seems like a pitfall for the unwary! At the very least, if they must be disallowed, could the error message be more informative? At the moment we get Setup.exe: Cabal.cabal:70: Unrecognized field format: 'Distribution.Simple.SetupWrapper,' It'd be better to get Setup.exe: Cabal.cabal:70: illegal tab character: replace with spaces Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/libraries/attachments/20070803/cea15d5c/attachment.htm From duncan.coutts at worc.ox.ac.uk Fri Aug 3 15:46:56 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 3 15:38:02 2007 Subject: Cabal bug In-Reply-To: References: Message-ID: <1186170416.5989.225.camel@localhost> On Fri, 2007-08-03 at 20:34 +0100, Simon Peyton-Jones wrote: > I have not been following the recent work on Cabal, but I tried to > build in the gap before this patch was committed. I > > Fri Aug 3 18:57:01 GMT Daylight Time 2007 Thomas Schilling > > > * Fix tab in Cabal.cabal. > > I was surprised to find that tabs are disallowed in cabal files. Is > that really the intention? Yes, since the new configurations format is layout sensitive. So tabs are disallowed in initial whitespace in cabal files that use the new features. Existing files should not be affected. > It seems like a pitfall for the unwary! At the very least, if they > must be disallowed, could the error message be more informative? At > the moment we get Yes, Thomas fixed that just now, > Setup.exe: Cabal.cabal:70: Unrecognized field format: > 'Distribution.Simple.SetupWrapper,' > > It?d be better to get > > Setup.exe: Cabal.cabal:70: illegal tab character: > replace with spaces the error message is now: setup: Cabal.cabal:70: Tabs used for indentation at (line,column): [(70,0),(71,1)] That was for a test case where tabs were used in two places of course. Duncan From simonpj at microsoft.com Fri Aug 3 15:55:27 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Aug 3 15:47:44 2007 Subject: Cabal bug In-Reply-To: <1186170416.5989.225.camel@localhost> References: <1186170416.5989.225.camel@localhost> Message-ID: | the error message is now: | | setup: Cabal.cabal:70: Tabs used for indentation at (line,column): | [(70,0),(71,1)] Great! It would be helpful to add "Use spaces instead". Otherwise the user might think "I know tabs are used for indentation -- I put them there". Simon From nominolo at googlemail.com Fri Aug 3 17:45:13 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 3 17:37:30 2007 Subject: Cabal bug In-Reply-To: References: Message-ID: <47766308-5407-4E70-A305-FEB1908E3FF0@googlemail.com> On 3 aug 2007, at 21.34, Simon Peyton-Jones wrote: > I have not been following the recent work on Cabal, but I tried to > build in the gap before this patch was committed. I > > Fri Aug 3 18:57:01 GMT Daylight Time 2007 Thomas Schilling > > > * Fix tab in Cabal.cabal. > > > > I was surprised to find that tabs are disallowed in cabal files. > Is that really the intention? It seems like a pitfall for the > unwary! At the very least, if they must be disallowed, could the > error message be more informative? At the moment we get > > Setup.exe: Cabal.cabal:70: Unrecognized field > format: 'Distribution.Simple.SetupWrapper,' > > > > It?d be better to get > > Setup.exe: Cabal.cabal:70: illegal tab character: > replace with spaces The problem is, that with conditional statements in .cabal files we really want to allow indenting the field values, e.g., if os(linux) { field: value } else { other-field: value . continuation of field value. } Therefore, we had to change the rule for multiline field values to: "To continue a field value, indent the next line _relative to the field name_." (emphasis added) This, unfortunately, made .cabal files susceptible to tab-length. My initial fix (defining tabs to be 8 spaces wide) was rejected[1], and I implemented this (backwards compatible) fix instead. Most (decent) editors can be configured to always use spaces instead of tabs. /Thomas [1] .. excerpt from IRC logs for #ghc, search for "No tabs in .cabal files" http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations From duncan.coutts at worc.ox.ac.uk Fri Aug 3 18:00:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 3 17:51:16 2007 Subject: Cabal bug In-Reply-To: References: <1186170416.5989.225.camel@localhost> Message-ID: <1186178412.5989.230.camel@localhost> On Fri, 2007-08-03 at 20:55 +0100, Simon Peyton-Jones wrote: > | the error message is now: > | > | setup: Cabal.cabal:70: Tabs used for indentation at (line,column): > | [(70,0),(71,1)] > > Great! It would be helpful to add "Use spaces instead". Otherwise > the user might think "I know tabs are used for indentation -- I put > them there". Thomas has improved it to say: + "Do not use tabs for indentation (use spaces instead)\n" + ++ " Tabs were used at (line,column): " ++ show tabs Duncan From ashley at semantic.org Fri Aug 3 18:22:54 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Aug 3 18:15:27 2007 Subject: Good Haskell Style In-Reply-To: <20070803185707.GI20161@darcs.net> References: <20070801141959.GA5993@matrix.chaos.earth.li> <20070803185707.GI20161@darcs.net> Message-ID: David Roundy wrote: >> * Use one tab to indent each level. Display them at 4 space boundaries. > > But this means that your code will have the possibility of layout bugs that > not visible to the programmer, since according to the report a tab > corresponds to eight spaces. Sounds like the worst of all possible > worlds. No layout bugs: * Use explicit braces and semicolons. Use "Allman" style. -- Ashley Yakeley From isaacdupree at charter.net Fri Aug 3 19:34:44 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 3 19:35:22 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <20070803185707.GI20161@darcs.net> Message-ID: <46B3BB94.1000102@charter.net> Ashley Yakeley wrote: > No layout bugs: > > * Use explicit braces and semicolons. Use "Allman" style. > I'm sure you could come up with a little better convention than this, but here you go (or does "Allman style" refer to something particular? if so, what?) : module Foo (bar, Baz(..)) where { import Prelude ; bar :: Ordering -> Bool ; bar x = case x of { LT -> True; _ -> False } ; data Baz a where { Oops :: Num a => Bool -> IO a -> Baz a ; Fine :: Baz () } } Oh by the way Ashley Y, have you seen my comment about the HaskellWiki at the end of http://haskell.org/haskellwiki/Talk:Haskell (I know this is off topic but I don't want to be spam-filtered or missed again!) Isaac From isaacdupree at charter.net Fri Aug 3 19:40:16 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 3 19:40:55 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> <20070802171929.GD26066@darcs.net> Message-ID: <46B3BCE0.4050800@charter.net> Jon Fairbairn wrote: > David Roundy writes: > >> On Thu, Aug 02, 2007 at 11:48:37AM +0100, Jon Fairbairn wrote: >>> [1] this isn't the only place where a version control system >>> that understood more of the language would be useful: for >>> example, rather than having to specify a regexp, I'd like >>> darcs replace to pick one (from a configuration file?) >>> depending on language. >> This latter bit is pretty easily added, but I doubt many people have >> repositories in which they use darcs replace often on multiple languages, >> so it seems like it ought to be pretty low-priority. > > I wasn't particularly thinking of multiple languages. The > default is wrong for Haskell, for example, so I have to put > something in _darcs/prefs/defaults. And it's not there when darcs-getting a repository of Haskell code, which is rather irritating since contributed patches SHOULD use the appropriate convention (for patch commutation as well as correctness of replacement). Although, I'm not sure how this can be fixed in the darcs model of looking at things? Isaac From ashley at semantic.org Fri Aug 3 20:30:44 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Aug 3 20:23:36 2007 Subject: Good Haskell Style In-Reply-To: <46B3BB94.1000102@charter.net> References: <20070801141959.GA5993@matrix.chaos.earth.li> <20070803185707.GI20161@darcs.net> <46B3BB94.1000102@charter.net> Message-ID: Isaac Dupree wrote: >> * Use explicit braces and semicolons. Use "Allman" style. >> > > I'm sure you could come up with a little better convention than this, > but here you go (or does "Allman style" refer to something particular? > if so, what?) : module Foo (bar, Baz(..)) where { import Prelude; bar :: Ordering -> Bool; bar x = case x of { LT -> True; _ -> False; }; data Baz a where { Oops :: Num a => Bool -> IO a -> Baz a; Fine :: Baz (); } } (but I've used spaces here) > Oh by the way Ashley Y, have you seen my comment about the HaskellWiki > at the end of http://haskell.org/haskellwiki/Talk:Haskell (I know this > is off topic but I don't want to be spam-filtered or missed again!) OK, I'll fix it... -- Ashley Yakeley From jon.fairbairn at cl.cam.ac.uk Sat Aug 4 05:21:31 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Aug 4 05:22:35 2007 Subject: Good Haskell Style References: <20070801141959.GA5993@matrix.chaos.earth.li> <5ab17e790708011306w2b218807h14f6ffe6b30853bd@mail.gmail.com> <20070801202141.GF26066@darcs.net> Message-ID: Benjamin Franksen writes: > I don't want you to do anything at all. I merely wanted to illustrate that > getting rid of trailing whitespace is easily automated. Well, let's say > half-automated: you still need to push the button. [...] > No crontab entry needed here The code was ironic ;-) > I agree that a darcs prehook (if they existed) would be an even nicer > solution. Quite. My point that computers are /for/ making things automatic. If they can remember to press the button, why should I have to? Or, less petulantly, being human I will inevitably forget sometimes (resulting in problems), where the machine wouldn't. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From ross at soi.city.ac.uk Sat Aug 4 09:26:38 2007 From: ross at soi.city.ac.uk (ross@soi.city.ac.uk) Date: Sat Aug 4 09:18:53 2007 Subject: patch applied (packages/containers): Remove the rest of base to leave a "containers" package In-Reply-To: <20070801224546.GA15410@cvs.haskell.org> References: <20070801224546.GA15410@cvs.haskell.org> Message-ID: <1186233998.46b47e8e4681d@fred.soi.city.ac.uk> Quoting Ian Lynagh : > Wed Aug 1 15:38:31 PDT 2007 Ian Lynagh > * Remove the rest of base to leave a "containers" package There may be a case for treating the constructor classes (in Data.Foldable and Data.Traversable) differently from the concrete container types (Data.Set et al). For example, to accomodate the instances for Array in the current setup, one of array and containers must depend on the other, although they are not otherwise related. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From duncan.coutts at worc.ox.ac.uk Sat Aug 4 09:44:24 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 4 09:35:28 2007 Subject: patch applied (packages/containers): Remove the rest of base to leave a "containers" package In-Reply-To: <1186233998.46b47e8e4681d@fred.soi.city.ac.uk> References: <20070801224546.GA15410@cvs.haskell.org> <1186233998.46b47e8e4681d@fred.soi.city.ac.uk> Message-ID: <1186235064.5989.271.camel@localhost> On Sat, 2007-08-04 at 14:26 +0100, ross@soi.city.ac.uk wrote: > Quoting Ian Lynagh : > > Wed Aug 1 15:38:31 PDT 2007 Ian Lynagh > > * Remove the rest of base to leave a "containers" package > > There may be a case for treating the constructor classes (in Data.Foldable > and Data.Traversable) differently from the concrete container types > (Data.Set et al). For example, to accomodate the instances for Array in > the current setup, one of array and containers must depend on the other, > although they are not otherwise related. I'd certainly argue for this too, the classes should be lower down the package tree than the instances, otherwise it discourages people from making their data types instances of these useful classes. Same argument applies to deriving generics support; that now requires depending on the generic package, even if it's no functions from it are used. Duncan From bulat.ziganshin at gmail.com Sat Aug 4 11:14:09 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Aug 4 11:10:13 2007 Subject: patch applied (packages/containers): Remove the rest of base to leave a "containers" package In-Reply-To: <1186235064.5989.271.camel@localhost> References: <20070801224546.GA15410@cvs.haskell.org> <1186233998.46b47e8e4681d@fred.soi.city.ac.uk> <1186235064.5989.271.camel@localhost> Message-ID: <1177659403.20070804191409@gmail.com> Hello Duncan, Saturday, August 4, 2007, 5:44:24 PM, you wrote: > I'd certainly argue for this too, the classes should be lower down the > package tree than the instances, otherwise it discourages people from > making their data types instances of these useful classes. > Same argument applies to deriving generics support; that now requires > depending on the generic package, even if it's no functions from it are > used. "lower down" - ok, but not in base if possible. base can't be upgraded without upgrading ghc and anything contained here is almost dead for timely improvements -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From isaacdupree at charter.net Sat Aug 4 16:34:32 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Aug 4 16:35:24 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <20070803185707.GI20161@darcs.net> <46B3BB94.1000102@charter.net> Message-ID: <46B4E2D8.5030509@charter.net> Ashley Yakeley wrote: > Isaac Dupree wrote: >>> * Use explicit braces and semicolons. Use "Allman" style. >>> >> >> I'm sure you could come up with a little better convention than this, >> but here you go (or does "Allman style" refer to something particular? >> if so, what?) : > > Okay, luckily Haskell generally allows extra semicolons, so that works :-) (in fact I believe the extra semicolons being allowed was important for flexible _layout_ rules, for use in combination with explicit semicolons, and thereby helped make sure that non-layout syntax was nice and flexible too!) Isaac From isaacdupree at charter.net Sat Aug 4 16:51:29 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Aug 4 16:52:26 2007 Subject: patch applied (packages/containers): Remove the rest of base to leave a "containers" package In-Reply-To: <1177659403.20070804191409@gmail.com> References: <20070801224546.GA15410@cvs.haskell.org> <1186233998.46b47e8e4681d@fred.soi.city.ac.uk> <1186235064.5989.271.camel@localhost> <1177659403.20070804191409@gmail.com> Message-ID: <46B4E6D1.20503@charter.net> Bulat Ziganshin wrote: > "lower down" - ok, but not in base if possible. base can't be upgraded > without upgrading ghc and anything contained here is almost dead for > timely improvements > Is it time to take Prelude and many classes out of base so they can be upgraded too, maybe a 'prelude', maybe a 'base-classes' package? Of course naming will be difficult and once base has shrunk enough, maybe it should be called something other than "base" then, although that's not necessary. Arguing for Prelude is if something in the library needs to be fixed up for Haskell-prime compliance sometime (the only change that seems likely to happen to Prelude!). On the other hand many of the standard classes and instances are currently defined in a way that is tangled amongst the un-upgradable code, so problems with those standard instances (like maybe) might not actually be fixable anyway without more-extensive refactoring work. Also arguing against taking Prelude out of base is if base is supposed to support some compilers that can't handle Prelude not being available! Packages consisting of only classes are mostly good, but they require the types they refer to and default implementations. Not much of a problem - class-default implementations probably shouldn't be too complicated. Isaac From ndmitchell at gmail.com Mon Aug 6 06:26:56 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Aug 6 06:19:01 2007 Subject: Library proposal: Add System.Info.isWindows Message-ID: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> Hi See bug: http://hackage.haskell.org/trac/ghc/ticket/1590 Currently the recognised way to test if your application is being run on Windows is: import System.Info .... = os == "mingw" This is wrong on so many levels! # The return result of os is NOT an operating system # The result mingw does not imply that mingw is installed # String comparisons are not very safe, a typo stops this working # In GHC this comparison will take place at runtime, even though its a constant Since nearly all uses of System.Info.os are to check if the operating system is Windows, adding an explicit isWindows function would simplify things. Proposal: Add System.Info.isWindows :: Bool This value should return True on all Windows systems (Win 1.0 ... Vista), and False on all other systems. Thanks Neil From bulat.ziganshin at gmail.com Mon Aug 6 07:39:58 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 6 07:36:13 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> Message-ID: <1072548517.20070806153958@gmail.com> Hello Neil, Monday, August 6, 2007, 2:26:56 PM, you wrote: > Proposal: > Add System.Info.isWindows :: Bool > This value should return True on all Windows systems (Win 1.0 ... > Vista), and False on all other systems. important question - what it should return on cygwin (and win32-emulating environments on unix if such ones exist) may be [another] good candidate will be a function that returns API? win32/win64/posix/... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Mon Aug 6 08:18:36 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 6 08:09:30 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> Message-ID: <1186402716.25415.44.camel@localhost> On Mon, 2007-08-06 at 11:26 +0100, Neil Mitchell wrote: > Proposal: > > Add System.Info.isWindows :: Bool > > This value should return True on all Windows systems (Win 1.0 ... > Vista), and False on all other systems. How about something slightly more general but still not quite so free form as the current System.Info.os :: String. Ian just added something to Cabal for it's own internal use to clean up the use of os-specific #cppery and use of System.Info.os which seems reasonable to me: data OS = Linux | Windows Windows | ... etc | Other String data Windows = MingW os :: OS So it's easy to pattern match on it and it gives us the ability to be more or less specific. For example in the windows case we could distinguish the environment, native vs mingw vs cygwin. That generalises isWindows and means we don't need isLinux, isOSX etc etc. Or if people really want those they can define them in terms of the above. So I suggest this (or something like it) as an alternative. While we're at it, discussing System.Info I think there are several more useful things we could add there, like exeExtension and probably several more. I seem to recall someone proposed a reasonable list on this mailing list some time ago, not just obj and dllExtension but a slightly wider rang of things. I can't seem to find it right now, does anyone else remember? Duncan From ndmitchell at gmail.com Mon Aug 6 08:36:54 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Aug 6 08:28:59 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <1186402716.25415.44.camel@localhost> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <1186402716.25415.44.camel@localhost> Message-ID: <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> Hi > important question - what it should return on cygwin (and > win32-emulating environments on unix if such ones exist) Very good question. I guess we should return the host operating system - i.e. Windows on Windows, and Unix on Unix. The emulation is generally for programs that aren't cross compatible, if you've taken the time to figure out what OS you are really on, you can probably be compatible to it. > How about something slightly more general but still not quite so free > form as the current System.Info.os :: String. > > Ian just added something to Cabal for it's own internal use to clean up > the use of os-specific #cppery and use of System.Info.os which seems > reasonable to me: > > data OS = Linux | Windows Windows | ... etc | Other String > data Windows = MingW Since when did GNU build Windows operating systems? You can add System.Info.libraries :: [Libary], and make MingW a library, but if you have a Windows enumeration it really should be for a list of Windows operating systems. > So it's easy to pattern match on it and it gives us the ability to be > more or less specific. For example in the windows case we could > distinguish the environment, native vs mingw vs cygwin. > That generalises isWindows and means we don't need isLinux, isOSX etc > etc. Or if people really want those they can define them in terms of the > above. I still propose isWindows. Checking "is this operating system windows" is the most common thing to do with System.Info.os, so should be easily accessible and foolproof. I would be perfectly happy to have something else as well, and implement isWindows on top of it. > While we're at it, discussing System.Info I think there are several more > useful things we could add there, like exeExtension and probably several > more. I seem to recall someone proposed a reasonable list on this > mailing list some time ago, not just obj and dllExtension but a slightly > wider rang of things. I can't seem to find it right now, does anyone > else remember? I believe Dimitry proposed them about 3 weeks ago. There are lots of things that could go in System.Info, and I agree more should be moved along. Thanks Neil From bulat.ziganshin at gmail.com Mon Aug 6 09:35:41 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Aug 6 09:31:54 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <1186402716.25415.44.camel@localhost> <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> Message-ID: <1186077056.20070806173541@gmail.com> Hello Neil, Monday, August 6, 2007, 4:36:54 PM, you wrote: >> important question - what it should return on cygwin (and >> win32-emulating environments on unix if such ones exist) > Very good question. I guess we should return the host operating system > - i.e. Windows on Windows, and Unix on Unix. The emulation is > generally for programs that aren't cross compatible, if you've taken > the time to figure out what OS you are really on, you can probably be > compatible to it. i think it's better to ask people which has cygwin experience overall, i agree with you - it will be great to add isWindows now. details of its behavior may be outlined based on further experience (i bet that there are no cygwin haskell developers at this moment). my only anxiety that it should be put outside of base -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From nad at cs.chalmers.se Mon Aug 6 11:12:18 2007 From: nad at cs.chalmers.se (Nils Anders Danielsson) Date: Mon Aug 6 11:04:28 2007 Subject: Good Haskell Style In-Reply-To: <8962BD11-B6CE-46D1-9815-ED78C73B0D7C@googlemail.com> (Thomas Schilling's message of "Thu, 2 Aug 2007 18:16:25 +0200") References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> <46B2006C.6030000@davidb.org> <8962BD11-B6CE-46D1-9815-ED78C73B0D7C@googlemail.com> Message-ID: On Thu, 02 Aug 2007, Thomas Schilling wrote: > (defun delete-trailing-space () FYI: There is a standard function delete-trailing-whitespace which you could use. > (add-hook 'write-file-hooks 'delete-trailing-space) And write-contents-hooks may be more appropriate. -- /NAD From nominolo at googlemail.com Mon Aug 6 14:44:05 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Aug 6 14:36:13 2007 Subject: Good Haskell Style In-Reply-To: References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> <46B2006C.6030000@davidb.org> <8962BD11-B6CE-46D1-9815-ED78C73B0D7C@googlemail.com> Message-ID: <2AB6D1C2-89B3-452D-A248-9774ACABA1E8@googlemail.com> On 6 aug 2007, at 17.12, Nils Anders Danielsson wrote: > On Thu, 02 Aug 2007, Thomas Schilling wrote: > >> (defun delete-trailing-space () Yes, thanks. That was also pointed out by Chris, in this thread. > FYI: There is a standard function delete-trailing-whitespace which you > could use. > >> (add-hook 'write-file-hooks 'delete-trailing-space) > > And write-contents-hooks may be more appropriate. Thanks, I take a look. As Simon Marlow mentioned, this however does not solve our problem. I just fell into that trap myself, because I accidentally kept that hook on a file I was working on, and had a very hard time filtering out the actual changes when I recorded my darcs patch. Hooking this feature in with highlight-changes-mode might give us a way to find out which lines were actually modified, but even then the best way to integrate this would be with darcs or some darcs mode. I use darcsum.el, which works rather well, but is far from perfect. I take a look. Thanks, / Thomas From nad at cs.chalmers.se Mon Aug 6 15:52:19 2007 From: nad at cs.chalmers.se (Nils Anders Danielsson) Date: Mon Aug 6 15:44:25 2007 Subject: Good Haskell Style In-Reply-To: <2AB6D1C2-89B3-452D-A248-9774ACABA1E8@googlemail.com> (Thomas Schilling's message of "Mon, 6 Aug 2007 20:44:05 +0200") References: <20070801141959.GA5993@matrix.chaos.earth.li> <5E32EA02-05A9-4C76-B5F9-48BE236B8374@googlemail.com> <46B1AD8E.1020007@gmail.com> <557EA0B8-896B-4B75-ACE9-1AAB1E72F2B5@googlemail.com> <46B2006C.6030000@davidb.org> <8962BD11-B6CE-46D1-9815-ED78C73B0D7C@googlemail.com> <2AB6D1C2-89B3-452D-A248-9774ACABA1E8@googlemail.com> Message-ID: On Mon, 06 Aug 2007, Thomas Schilling wrote: > As Simon Marlow mentioned, this however does not solve our problem. No, it does not solve Simon's problem, but it is a quick and simple solution which works well for files that are created and edited only by you. Furthermore a little white space in some patches may not be much of a problem. -- /NAD From nominolo at googlemail.com Mon Aug 6 16:24:00 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Aug 6 16:16:07 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> Message-ID: <14D9E2A0-DEFD-481A-9EC1-7508E4EDBDB0@googlemail.com> On 6 aug 2007, at 12.26, Neil Mitchell wrote: > .... = os == "mingw" > > This is wrong on so many levels! I agree, but > Proposal: > > Add System.Info.isWindows :: Bool is hardly better, because this opens the door to political issues (why not have isLinux, isFreeBSD, isNetBSD, ...?) And I'm not even sure returning True for every Windows incarnation is the right thing in most use cases. In general you want to test for APIs--not the OS per se. I am much for an ADT instead of an unstandardized String, but having a battery of is is not a solution -- a library/program should be able to decide for itself how much info about it's environment it needs. (e.g., isWindows on cygwin depends really on what information you need, like for calling certain libraries, or just have a different UI style, etc.) / Thomas From isaacdupree at charter.net Mon Aug 6 17:04:41 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Aug 6 17:06:07 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <14D9E2A0-DEFD-481A-9EC1-7508E4EDBDB0@googlemail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <14D9E2A0-DEFD-481A-9EC1-7508E4EDBDB0@googlemail.com> Message-ID: <46B78CE9.3080805@charter.net> Thomas Schilling wrote: > On 6 aug 2007, at 12.26, Neil Mitchell wrote: >> .... = os == "mingw" >> >> This is wrong on so many levels! > > I agree, but > >> Proposal: >> >> Add System.Info.isWindows :: Bool > > is hardly better, because this opens the door to political issues (why > not have isLinux, isFreeBSD, isNetBSD, ...?) And I'm not even sure > returning True for every Windows incarnation is the right thing in most > use cases. In general you want to test for APIs--not the OS per se. Like it or not, Windows is a very significant, special case, where programs often transform themselves, more than they need to, based on a simple judgment of whether they're on "windows" or not, even when POSIX APIs are available, etc., etc. ***I don't like it either.*** But defining APIs is hard work, Windows is in practice much different from almost anything else, much more important, and many of us aren't interested in expending too much hard work to support (flexibly, in detail,) stupid closed-source platforms. Developers tend to want to check for isWindows anyway: they already do, with os=="mingw" and other hacks. ***I think isWindows is necessary, at least as a intermediate solution***... if someone makes more, API-specific queries sometime, then it will be easier to search existing code for the unified "isWindows" and find everywhere that might be improved. I vote *against* the name isMicrosoftWindows because the query *should* return True in ReactOS / Wine, assuming Haskell and them can be made to work at all! Any differences there, should be resolved by more detailed queries (e.g. Window OS version number! - or whatever they use for labelling their versions) Isaac From john at repetae.net Mon Aug 6 18:09:19 2007 From: john at repetae.net (John Meacham) Date: Mon Aug 6 18:01:23 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <46B78CE9.3080805@charter.net> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <14D9E2A0-DEFD-481A-9EC1-7508E4EDBDB0@googlemail.com> <46B78CE9.3080805@charter.net> Message-ID: <20070806220919.GA28633@momenergy.repetae.net> On Mon, Aug 06, 2007 at 06:04:41PM -0300, Isaac Dupree wrote: > Thomas Schilling wrote: > >On 6 aug 2007, at 12.26, Neil Mitchell wrote: > >>.... = os == "mingw" > >> > >>This is wrong on so many levels! > > > >I agree, but > > > >>Proposal: > >> > >>Add System.Info.isWindows :: Bool > > > >is hardly better, because this opens the door to political issues (why > >not have isLinux, isFreeBSD, isNetBSD, ...?) And I'm not even sure > >returning True for every Windows incarnation is the right thing in most > >use cases. In general you want to test for APIs--not the OS per se. > > Like it or not, Windows is a very significant, special case, where > programs often transform themselves, more than they need to, based on a > simple judgment of whether they're on "windows" or not, even when POSIX > APIs are available, etc., etc. ***I don't like it either.*** But > defining APIs is hard work, Windows is in practice much different from > almost anything else, much more important, and many of us aren't > interested in expending too much hard work to support (flexibly, in > detail,) stupid closed-source platforms. Developers tend to want to > check for isWindows anyway: they already do, with os=="mingw" and other > hacks. ***I think isWindows is necessary, at least as a intermediate > solution***... if someone makes more, API-specific queries sometime, > then it will be easier to search existing code for the unified > "isWindows" and find everywhere that might be improved. Yes. I agree, I wouldn't want to see an enumerated data type, because you really want to query features the environment supports, not necessarily what OS. (like, ReactOS provides the win32 api) so, I'd actually like to see two isWindows :: Bool isPosix :: Bool where they say whether the given APIs are available (to some reasonable approximation). for instance, windows under mingw would be True,False, while windows under cygwin would be True,True and linux would be False,True. This covers the 'special' cases that most people have to worry about. I have nothing against a more complete API, but these two special cases are common and important enough that I think they should have special support. John -- John Meacham - ?repetae.net?john? From bulat.ziganshin at gmail.com Tue Aug 7 01:37:38 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Aug 7 01:34:27 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <14D9E2A0-DEFD-481A-9EC1-7508E4EDBDB0@googlemail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <14D9E2A0-DEFD-481A-9EC1-7508E4EDBDB0@googlemail.com> Message-ID: <488019993.20070807093738@gmail.com> Hello Thomas, Tuesday, August 7, 2007, 12:24:00 AM, you wrote: >> .... = os == "mingw" > is hardly better, because this opens the door to political issues > (why not have isLinux, isFreeBSD, isNetBSD, ...?) i bet that above-mentioned System.Info.os should alow to test for these situations. it return unix-specific string so it should be good to distinguish any unix OSes and only recognizing windows is a problem -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From igloo at earth.li Tue Aug 7 08:04:59 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Aug 7 07:57:01 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <1186402716.25415.44.camel@localhost> <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> Message-ID: <20070807120459.GA13714@matrix.chaos.earth.li> On Mon, Aug 06, 2007 at 01:36:54PM +0100, Neil Mitchell wrote: > > Proposal: > > Add System.Info.isWindows :: Bool I was actually planning to propose something along similar lines this week, in order to replace ifdef's like in the GHC and library sources with pattern matches like I have done in Cabal, e.g.: -#if mingw32_HOST_OS || mingw32_TARGET_OS -dllExtension = "dll" -#else -dllExtension = "so" -#endif +dllExtension = case os of + Windows _ -> "dll" + _ -> "so" I haven't been through to look at what ifdef-replacements are needed, but I expect to want both OS = Linux | Windows Windows | ... | OtherOS String and Arch = I386 | AMD64 | Sparc | ... | OtherArch String types. Not all ifdefs will be able to be removed, e.g. because they use platform-specific packages or foreign imports. I don't know if it would be worth having other extensions to make elmiinating these ifdefs possible too. I would like it to be easy for an optimiser to dead-code-eliminate branches that don't apply (and in particular I would like it to be something that is DCEd by GHC so we don't carry around entire NCGs we can't use, for example). As long as that happens I don't really mind if it is done by pattern matching or by using isWindows-style functions. Doing equality tests against System.Info.os doesn't cut it, though. Finally, it needs to remain in base if we are to use it for ifdef-removal in the base libraries (and as low down in base as possible). > > data OS = Linux | Windows Windows | ... etc | Other String > > data Windows = MingW > > Since when did GNU build Windows operating systems? It seemed to me that at some point we would be likely to want to distinguish between MingW | Cygwin | Native, but a lot of the time we'd want to just match Windows _. > You can add > System.Info.libraries :: [Libary], and make MingW a library, but if > you have a Windows enumeration it really should be for a list of > Windows operating systems. We'd need to do IO to do that, so it wouldn't fit my needs. Also, MingW `elem` libraries wouldn't get optimised out at compile time. It would be great if we could get all this into 6.8, as then we will be able to rely on it a year or so earlier. > There are lots of things that could go in System.Info, and I agree > more should be moved along. Ditto for these. Thanks Ian From isaacdupree at charter.net Tue Aug 7 08:40:25 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Aug 7 08:42:04 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <20070807120459.GA13714@matrix.chaos.earth.li> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <1186402716.25415.44.camel@localhost> <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> <20070807120459.GA13714@matrix.chaos.earth.li> Message-ID: <46B86839.9080802@charter.net> Ian Lynagh wrote: > Finally, it needs to remain in base if we are to use it for > ifdef-removal in the base libraries (and as low down in base as > possible). Would it be helpful to know the full set of platform-tests base currently uses, so we know a minimum of what tests we need in base? And... there is always the "code duplication" approach, if anything needs to be used in base as well as being upgradable, although I would not recommend that approach (unless with a detailed consideration) :-) Isaac From naesten at gmail.com Wed Aug 8 22:30:36 2007 From: naesten at gmail.com (Samuel Bronson) Date: Wed Aug 8 22:22:32 2007 Subject: "Data.TupleFields" for review Message-ID: Hi. I wrote a module and dons suggested I ask you guys for some tips. Here's a good deal of it: ----------------------------------------------------------------------------- -- | -- Module : Data.TupleFields -- Copyright : (c) 2007 Samuel Bronson -- License : BSD3-style -- -- Maintainer : naesten@gmail.com -- Stability : experimental -- Portability : non-portable (multi-param classes, functional dependencies) -- -- -- This module provides tuple field access similar to ML's #1, #2 etc. -- ------------------------------------------------------------------------ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Data.TupleFields where import Data.Tuple class Field1 t f | t -> f where field1 :: t -> f field1_u :: (f -> f) -> (t -> t) field1_s :: f -> (t -> t) field1_s x = field1_u (const x) class Field1 t f1 => Field2 t f1 f | t -> f where field2 :: t -> f field2_u :: (f -> f) -> (t -> t) field2_s :: f -> (t -> t) field2_s x = field2_u (const x) class Field2 t f1 f2 => Field3 t f1 f2 f | t -> f where field3 :: t -> f field3_u :: (f -> f) -> (t -> t) field3_s :: f -> (t -> t) field3_s x = field3_u (const x) class Field3 t f1 f2 f3 => Field4 t f1 f2 f3 f | t -> f where field4 :: t -> f field4_u :: (f -> f) -> (t -> t) field4_s :: f -> (t -> t) field4_s x = field4_u (const x) class Field4 t f1 f2 f3 f4 => Field5 t f1 f2 f3 f4 f | t -> f where field5 :: t -> f field5_u :: (f -> f) -> (t -> t) field5_s :: f -> (t -> t) field5_s x = field5_u (const x) class Field5 t f1 f2 f3 f4 f5 => Field6 t f1 f2 f3 f4 f5 f | t -> f where field6 :: t -> f field6_u :: (f -> f) -> (t -> t) field6_s :: f -> (t -> t) field6_s x = field6_u (const x) class Field6 t f1 f2 f3 f4 f5 f6 => Field7 t f1 f2 f3 f4 f5 f6 f | t -> f where field7 :: t -> f field7_u :: (f -> f) -> (t -> t) field7_s :: f -> (t -> t) field7_s x = field7_u (const x) instance Field1 ((,) t1 t2) t1 where field1 ((,) x1 x2) = x1 field1_u f ((,) x1 x2) = (,) (f x1) x2 instance Field2 ((,) t1 t2) t1 t2 where field2 ((,) x1 x2) = x2 field2_u f ((,) x1 x2) = (,) x1 (f x2) instance Field1 ((,,) t1 t2 t3) t1 where field1 ((,,) x1 x2 x3) = x1 field1_u f ((,,) x1 x2 x3) = (,,) (f x1) x2 x3 instance Field2 ((,,) t1 t2 t3) t1 t2 where field2 ((,,) x1 x2 x3) = x2 field2_u f ((,,) x1 x2 x3) = (,,) x1 (f x2) x3 instance Field3 ((,,) t1 t2 t3) t1 t2 t3 where field3 ((,,) x1 x2 x3) = x3 field3_u f ((,,) x1 x2 x3) = (,,) x1 x2 (f x3) The module goes on to define instances for all the tuple types up through (,,,,,,) (7-tuples). Any suggestions? From lemming at henning-thielemann.de Thu Aug 9 09:16:19 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 9 09:08:18 2007 Subject: "Data.TupleFields" for review In-Reply-To: References: Message-ID: On Wed, 8 Aug 2007, Samuel Bronson wrote: > Hi. I wrote a module and dons suggested I ask you guys for some tips. > Here's a good deal of it: > > module Data.TupleFields where > > import Data.Tuple > > class Field1 t f | t -> f where > field1 :: t -> f > field1_u :: (f -> f) -> (t -> t) > field1_s :: f -> (t -> t) > field1_s x = field1_u (const x) Somewhen in the past I proposed a different usage of the field names of Haskell record fields: http://www.haskell.org/haskellwiki/Record_access Translated to the tuple issue, I use only one function of type field1 :: f -> t -> (f,t) which is a combination of 'get' and 'set'. Using this function you can implement a generic 'set', 'get', and 'update'. Of course, you can argue that it is bad style to put the distinct 'set' and 'get' functionalities into one function. Nevertheless, I think 'field1_u' should not be a class method, but there should be a separate 'update' function which combines 'field1_s' and 'field1'. I would also rename 'field' to 'field_g' or better use 'field1get', 'field1set', 'field1update' or 'field1modify' (in analogy to State monad from MTL). An excerpt with basic functions: type Accessor r a = a -> r -> (a, r) {- | Set the value of a field. -} set :: Accessor r a -> a -> r -> r set f x = snd . f x {- | Get the value of a field. -} get :: Accessor r a -> r -> a get f = fst . f undefined {- | Transform the value of a field by a function. -} modify :: Accessor r a -> (a -> a) -> (r -> r) modify f g rOld = let (a,rNew) = f (g a) rOld in rNew From naesten at gmail.com Thu Aug 9 10:02:28 2007 From: naesten at gmail.com (Samuel Bronson) Date: Thu Aug 9 09:54:22 2007 Subject: "Data.TupleFields" for review In-Reply-To: <1186643439.4442.85.camel@nmd9999> References: <1186643439.4442.85.camel@nmd9999> Message-ID: On 8/9/07, Ketil Malde wrote: > On Wed, 2007-08-08 at 22:30 -0400, Samuel Bronson wrote: > > > -- This module provides tuple field access similar to ML's #1, #2 etc. > > Perhaps the naming could be improved? > > Lisp calls these first, second, third, etc and nth for the general case. > (Ignoring the more esoterically named car, cadr, etc, and the fact that > they operate on lists) > > Also, I presume the abbreviations are _u for update, _s for set? Unless > this goes into a standard library (replacing fst and snd?) and thus > becomes ubiquitously used, I'd prefer less cryptic names, perhaps > mapFirst, setSecond, etc. I think 'map' gives the correct connotation, > rather than 'update'. The only convention I'd seen for this when I picked those names was the one that DrIFT implements, so that's what I used. I've since learned that Derive implements a different convention, with names like setFoo where DrIFT would have foo_s, though it doesn't seem to have an equivalent for foo_u. I'm not sure I want map; perhaps some variant of modify... > (Private reply only, as the list won't accept mail from an address the > MUA will let me use. Feel free to cite in public.) How do you know that the list won't accept mail from your address? From naesten at gmail.com Thu Aug 9 10:09:49 2007 From: naesten at gmail.com (Samuel Bronson) Date: Thu Aug 9 10:01:42 2007 Subject: "Data.TupleFields" for review In-Reply-To: References: Message-ID: On 8/9/07, Henning Thielemann wrote: > > On Wed, 8 Aug 2007, Samuel Bronson wrote: > > > Hi. I wrote a module and dons suggested I ask you guys for some tips. > > Here's a good deal of it: > > > > module Data.TupleFields where > > > > import Data.Tuple > > > > class Field1 t f | t -> f where > > field1 :: t -> f > > field1_u :: (f -> f) -> (t -> t) > > field1_s :: f -> (t -> t) > > field1_s x = field1_u (const x) > > Somewhen in the past I proposed a different usage of the field names of > Haskell record fields: > http://www.haskell.org/haskellwiki/Record_access > Translated to the tuple issue, I use only one function of type > field1 :: f -> t -> (f,t) > which is a combination of 'get' and 'set'. > Using this function you can implement a generic 'set', 'get', and > 'update'. Of course, you can argue that it is bad style to put the > distinct 'set' and 'get' functionalities into one function. Nevertheless, > I think 'field1_u' should not be a class method, but there should be a > separate 'update' function which combines 'field1_s' and 'field1'. I would > also rename 'field' to 'field_g' or better use 'field1get', 'field1set', > 'field1update' or 'field1modify' (in analogy to State monad from MTL). Hmm. How about getField1, setField1, modifyField1 etc.? Or see below. > type Accessor r a = a -> r -> (a, r) > > {- | Set the value of a field. -} > set :: Accessor r a -> a -> r -> r > set f x = snd . f x > > {- | Get the value of a field. -} > get :: Accessor r a -> r -> a > get f = fst . f undefined > > {- | Transform the value of a field by a function. -} > modify :: Accessor r a -> (a -> a) -> (r -> r) > modify f g rOld = > let (a,rNew) = f (g a) rOld > in rNew Hmm, these names are a bit *too* close to the ones used in the mtl ;-). Also, are you going to make a package implementing this basic interface (preferably with names that don't conflict with mtl), or should I include it in another module in my package? From isaacdupree at charter.net Thu Aug 9 10:10:26 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Aug 9 10:12:38 2007 Subject: "Data.TupleFields" for review In-Reply-To: References: Message-ID: <46BB2052.1000509@charter.net> Henning Thielemann wrote: > Translated to the tuple issue, I use only one function of type > field1 :: f -> t -> (f,t) > which is a combination of 'get' and 'set'. > Using this function you can implement a generic 'set', 'get', and > 'update'. Of course, you can argue that it is bad style to put the > distinct 'set' and 'get' functionalities into one function. I like that style. It reminds me of the zipper pattern, of accessors (or something like that). ...which is more important for more complicated things (Maps?) (Uniplate.) I don't know when I'd want to use a function polymorphic in tuple size - _personally_ I'd rather stick to simpler types and ... probably pattern-matching. It's too bad selectors via pattern-matching take a bit more syntax than (,,this,) unless you're already in a pattern-match location... ( (_,_,this,_) ). Large tuples whose size can change might be better represented with record syntax. So I'm not the target audience of this library :) Isaac From lemming at henning-thielemann.de Thu Aug 9 11:29:47 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Aug 9 11:21:45 2007 Subject: "Data.TupleFields" for review In-Reply-To: <46BB2052.1000509@charter.net> References: <46BB2052.1000509@charter.net> Message-ID: On Thu, 9 Aug 2007, Isaac Dupree wrote: > Henning Thielemann wrote: > > Translated to the tuple issue, I use only one function of type > > field1 :: f -> t -> (f,t) > > which is a combination of 'get' and 'set'. > > Using this function you can implement a generic 'set', 'get', and > > 'update'. Of course, you can argue that it is bad style to put the > > distinct 'set' and 'get' functionalities into one function. > > I like that style. It reminds me of the zipper pattern, of accessors (or > something like that). ...which is more important for more complicated > things (Maps?) (Uniplate.) > > I don't know when I'd want to use a function polymorphic in tuple size - > _personally_ I'd rather stick to simpler types and ... probably > pattern-matching. Me too. I think, I've never used other tuples than pairs and triples. Records are much clearer and safer. From ashley at semantic.org Thu Aug 9 19:33:04 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Aug 9 19:25:09 2007 Subject: gnomevfs2 Message-ID: Has anyone created Haskell bindings for gnomevfs2? -- Ashley Yakeley From john at repetae.net Thu Aug 9 20:57:45 2007 From: john at repetae.net (John Meacham) Date: Thu Aug 9 20:49:39 2007 Subject: Library proposal: Add System.Info.isWindows In-Reply-To: <20070807120459.GA13714@matrix.chaos.earth.li> References: <404396ef0708060326s22dfb71ek757fbcb5ca86b27f@mail.gmail.com> <1186402716.25415.44.camel@localhost> <404396ef0708060536q2f3c7c96v69db9d24eb6643d4@mail.gmail.com> <20070807120459.GA13714@matrix.chaos.earth.li> Message-ID: <20070810005745.GA1377@momenergy.repetae.net> On Tue, Aug 07, 2007 at 01:04:59PM +0100, Ian Lynagh wrote: > On Mon, Aug 06, 2007 at 01:36:54PM +0100, Neil Mitchell wrote: > I was actually planning to propose something along similar lines this > week, in order to replace ifdef's like in the GHC and library sources with > pattern matches like I have done in Cabal, e.g.: > > -#if mingw32_HOST_OS || mingw32_TARGET_OS > -dllExtension = "dll" > -#else > -dllExtension = "so" > -#endif > > +dllExtension = case os of > + Windows _ -> "dll" > + _ -> "so" Yes, removing ifdefs like this is very important to compilers such as jhc that produce portable C code, it is very unlikely the answers to these questions are available at compile time. especially when bundling a library for distribution. I would also like to see nativeWordSize and nativePointerSize fields of type Int. sizeof (undefined :: CInt) and sizeof (undefined :: Ptr a) sort of work... but are rather convoluted for such a common thing that needs to be queried. for targeted compilers such as ghc, these will be compile time constants so will optimize away, for ones such as jhc, the actual determination of the values may be defered. John -- John Meacham - ?repetae.net?john? From igloo at earth.li Fri Aug 10 11:05:51 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 10 10:57:42 2007 Subject: Proposal: Make arrays safer Message-ID: <20070810150551.GA5595@matrix.chaos.earth.li> Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1610 This is a proposal to make arrays safer, e.g. see: http://hackage.haskell.org/trac/ghc/ticket/1046 This is a divergence from Haskell 98. The patches: * Add (numElements :: Ix i => a i e -> Int) to IArray class * Array types get an extra field for numElements, e.g. -data UArray i e = UArray !i !i ByteArray# +data UArray i e = UArray !i !i !Int ByteArray# This is a cache of rangeSize(l,u) * Add safeRangeSize (always returns >= 0) * Add safeIndex (use unsafeIndex (no Ix inRange check), but check index < numElements) * unsafeForeignPtrToStorableArray gained an (Ix i) context * Use the new functions in various places Suggested deadline: 24 Aug 2007. Thanks