Good Haskell Style

[Ian Lynagh]

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


#!/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))%


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Marlow-5]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Philippa Cowderoy]

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
<snip>
> 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@...

A problem that's all in your head is still a problem.
Brain damage is but one form of mind damage.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[ChrisK-5]

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
> <snip>
>> 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@...
http://www.haskell.org/mailman/listinfo/libraries

[sethk]

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@... [mailto:libraries-bounces@...]
On Behalf Of Chris Kuklewicz
Sent: Wednesday, August 01, 2007 11:31 AM
To: Philippa Cowderoy
Cc: libraries@...; 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
> <snip>
>> 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@...
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Christian Maeder-2]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Thomas Schilling-2]

-----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-----
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Philippa Cowderoy]

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

"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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Malcolm Wallace]

> * 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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Iavor Diatchki]

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.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Thomas Schilling-2]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Thomas Schilling-2]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Isaac Dupree]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[John Meacham]

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⑈
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Peyton-Jones]

| * 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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bayley, Alistair-2]

> From: libraries-bounces@...
> [mailto:libraries-bounces@...] 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.
*****************************************************************
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries