On Sat, Sep 25, 2010 at 5:06 PM, Donn Cave wrote:

Though it's common practice for sure, maybe universal, does the "Don't insert a space after a lambda" rule make sense?

I found it confusing at first sight, because of course it looks like something else - in "\n m -> ...", to the uninitiated it represents a newline, for example.  Now that I understand that it's a symbolic keyword, it's an odd way to treat it.  This has probably come up before, so feel free to ignore, "I'm just saying."

I think I lean more towards surrounding "\" with spaces nowadays.

The white space I have trouble deciding on is one-line record syntax --  ARecord { aField = "a" }, or maybe ARecord {aField = "a"}.

I always do the former and I think it's the more common style.

Hi Johan, On Sat, Sep 25, 2010 at 01:44:07PM +0200, Johan Tibell wrote:

Quite a few people follow my style guide

http://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md

which codifies the style used in Real World Haskell, bytestring, text, and a few other libraries.

Thanks for sharing the link, it's quite helpful. It's just what I was looking for. One more thought: Do you also have some recommendations for formatting 'let ... in ...' expressions? Best regards, Petr

On Sun, 2010-09-26 at 11:40 +0200, Petr Pudlak wrote:

Hi Johan,

On Sat, Sep 25, 2010 at 01:44:07PM +0200, Johan Tibell wrote:

...

Quite a few people follow my style guide

http://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md

which codifies the style used in Real World Haskell, bytestring, text, and a few other libraries.

Thanks for sharing the link, it's quite helpful. It's just what I was looking for.

One more thought: Do you also have some recommendations for formatting 'let ... in ...' expressions?

Best regards, Petr

I use it in following way; 1. For short sharing name (rarely) let a = b ++ c in (a, a) 2. Default let a :: [Int] a = b ++ c f :: Int -> String f 0 = "" f x = show x in map f a Regards

Hi, On 01.10.2010, at 09:57, Wolfgang Jeltsch wrote:

I think this is much more readable, since you can easily see which of those lines belong together.

I wonder whether there are empirical results which show that a certain kind of spacing is more readable for a certain kind of programmer (for example, experienced, novice, ...). I remember that I once read a paper about camelCase vs. underscore function names. I think that they came to the conclusion that camelCase is advantages for non-programmers but there was no difference when they tested programmers. But I might be wrong here. Cheers, Jan

On Sun, Sep 26, 2010 at 12:31 PM, Maciej Piechotka wrote:

May I ask clarification about formatting (according to your convention)

doSomething :: (a -> a -> a) -> a -> a -> a doSomething f x = f y y                  where y = f x x

I always put 2 spaces before the where clause.

On Mon, Sep 27, 2010 at 8:20 AM, Richard O'Keefe wrote:

On Sep 27, 2010, at 5:31 AM, Maciej Piechotka wrote:

...

May I ask clarification about formatting (according to your convention)

doSomething :: (a -> a -> a) -> a -> a -> a doSomething f x = f y y                  where y = f x x

i.e. single line function+where

There is a meta-rule that I use for indentation in a wide range of languages:  where the line breaks are may depend on identifier spelling, but what the indentation is should not.

In Haskell I sometimes violate that, but I usually end up regretting it.

+1 I use the same rule. My style looks like this. module Module where ( FancyType (..) , main ) data FancyType a b = FirstConstructor a | SecondConstructor b deriving (Show) f a b | a > 0 = FisrtConstructor a | otherwise = SecondConstructor g where g = h b h = id main = do putStrLn hello putStrLn . concat [ hello , show (f 25 1) ] flip mapM_ [1..100] $ \n -> do print n putStrLn hello where hello = "Hello" I allways use spaces without tabs and allways use camelCase. -- Victor Nazarov

On Sun, Sep 26, 2010 at 12:50 PM, Henning Thielemann wrote:

Coding conventions are often a matter of individual taste. You may find some suggestions under  http://www.haskell.org/haskellwiki/Category:Style and choose the ones that you like.

Absolutely. However, having a consistent style, whatever it might be, does bring some benefits and hence there are style guides. :)

Quoth Alexander Solla , ...

That's not so nice looking now, but consider what happens when you have four or five arguments:

type Label = String type Address = String

data Foo a b = Foo (Maybe Label) Address a | Bar Label b | Foobar Label Address a b

This is rather neat. Instead of focusing effort on parsing the source, we can merely compare lines for the differences in logic they embody.

Note that it depends on a mono-spaced font. Works as intended in my terminal emulator window, and anywhere you or I have gone to the trouble, but my initial look at it was in my email, which as usual is a proportional font, and nothing lines up after the first column. Donn

On Monday 27 September 2010 14:52:18, Henning Thielemann wrote:

data Foo a b =      Foo    a    | Bar      b    | Foobar a b

avoids this, at least for the type name "Foo".

Tastes vary, but I find that ugly. I much rather have the '=' aligned with the '|'. data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord) There, that looks good. With the one exception that as a rule, in a multi-constructor type, none of the constructors should be identical to the type name (IMO).

On Monday 27 September 2010 18:09:08, Evan Laforge wrote:

...

data Foo a b    = Foo      a    | Bar        b    | Foobar  a b      deriving (Eq, Ord)

There, that looks good.

There is a trap if you do a similar thing with records:

data Foo = Foo { a :: Int , b :: Int }

If you use '-- |' style haddock it can't go on 'a'. Since I tend to want to put '-- |' on every field, I have to put the '{' on the previous line.

Hm, yes. I always use '-- ^' haddock comments for record fields, so that didn't occur to me.

As for other stuff, I don't like the vertical lining up thing. It's

I haven't tried it yet. I think aligning corresponding fields has advantages - it makes it rather obvious to see which constructor uses which parameter types in many cases. On the other hand, with many fields you get a very scattered picture if some constructors only have few. That looks ugly and isn't easy to take in at a glance. I don't think I'll adopt it, but I plan to try it out.

too much work to type in, causes too much realigning when the top line changes, sometimes causes things to get too far right,

Yep

and breaks entirely with proportional fonts.

Not relevant for me, when looking at Haskell or Python code, I value my fixed-width font, it just looks too weird in proportional fonts.

A plain indent as advocated above avoids all those problems.

On Mon, Sep 27, 2010 at 6:28 PM, Gregory Collins wrote:

Also, if you're reading code in a proportional font, "you're doing it wrong."

You may have nice codes using proportional fonts using LaTeX package 'listings'. Even in a proportional font it lines things up. Note, however, that you need to write *your* LaTeX source code in a fixed-width font for 'listings' to understand where things should be lined up. Unfortunately we don't have this mode in any editor as far as I know. And even if we did, I don't know how the same code would be viewed in another editor. Reading 'listings'-style LaTeX isn't funny, much less writing. Cheers! :) -- Felipe.

On 27/09/2010 02:44 PM, Daniel Fischer wrote:

...

data Foo a b = Foo a | Bar b | Foobar a b

avoids this, at least for the type name "Foo". Tastes vary, but I find that ugly. I much rather have the '=' aligned with

On Monday 27 September 2010 14:52:18, Henning Thielemann wrote: the '|'.

data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord)

There, that looks good.

Tastes do indeed vary. To me, both of these are incorrect, and the correct way is data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord) It honestly annoys me that Haddock disagrees with me on this point... (It also irritates me that almost all Haskell identifiers are camel-case, but with an inital lowercase letter. IMHO, the correct thing to do is use camel-case for identifiers that must begin with an uppercase letter, and underscores for identifiers that must begin with a lowercase letter. Of course, my opinion has no effect on the Prelude and so forth.) I generally try to structure my code so that all blocks indent by 2 spaces, and the size of indentation never depends on the length of an identifier. In other words, none of this: foo x y z = do thing1 x thing2 x y thing3 z ... Do that a few times and you rapidly end up with lines 300 characters wide. (!) Instead, I prefer foo x y z = do thing1 x thing2 x y thing3 z ... But, as they say, everybody has their own ideas about style. I think the most important point must surely be that any style is applied *consistently*...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/27/10 17:07 , Max Rabkin wrote:

On Mon, Sep 27, 2010 at 22:57, Andrew Coppin wrote:

...

data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord)

Also, either your pipes don't line up, or you violate your own rule

They line up fine in a fixed width font. Programming in any indentation-sensitive language in a proportional font leads inevitably to use of tabs to make things line up properly, which leads directly to pain. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyhHNcACgkQIn7hlCsL25XKjwCgjlxdAK1RTimZhFb0nzyYo5lu pXAAoLKdcuZ7foV+uM0s9QtvabFopuJl =WCR4 -----END PGP SIGNATURE-----

...

Also, either your pipes don't line up, or you violate your own rule

They line up fine in a fixed width font.  Programming in any indentation-sensitive language in a proportional font leads inevitably to use of tabs to make things line up properly, which leads directly to pain.

I write haskell and python in a proportional font and it hasn't yet let to tabs, so no pain so far :)

How do you guys indent long function arguments? I run into this all the time with the 'maybe' function which takes 3 arguments: maybe :: b -> (a -> b) -> Maybe a -> b I usually end up doing things like (pretend the arguments are aligned if you're not using a monospace font to view this): maybe do-if-Nothing (\x -> do-if-Just x) maybe-value This gets a little unwieldly if the any of the arguments stretch over one line like: maybe do-if-Nothing (\x -> ... ... something ) maybe-value Any advice on indentation? I could avoid the problem by adding a 'let' or 'where' but sometimes I like to show the entire function without the user having to scan another definition. -deech On Mon, Sep 27, 2010 at 3:57 PM, Andrew Coppin wrote:

 On 27/09/2010 02:44 PM, Daniel Fischer wrote:

...

On Monday 27 September 2010 14:52:18, Henning Thielemann wrote:

...

data Foo a b =      Foo    a    | Bar      b    | Foobar a b

avoids this, at least for the type name "Foo".

Tastes vary, but I find that ugly. I much rather have the '=' aligned with the '|'.

data Foo a b     = Foo      a     | Bar        b     | Foobar  a b       deriving (Eq, Ord)

There, that looks good.

Tastes do indeed vary. To me, both of these are incorrect, and the correct way is

 data Foo a b =      Foo    a   |      Bar      b |      Foobar a b    deriving (Eq, Ord)

It honestly annoys me that Haddock disagrees with me on this point...

(It also irritates me that almost all Haskell identifiers are camel-case, but with an inital lowercase letter. IMHO, the correct thing to do is use camel-case for identifiers that must begin with an uppercase letter, and underscores for identifiers that must begin with a lowercase letter. Of course, my opinion has no effect on the Prelude and so forth.)

I generally try to structure my code so that all blocks indent by 2 spaces, and the size of indentation never depends on the length of an identifier. In other words, none of this:

 foo x y z = do              thing1 x              thing2 x y              thing3 z              ...

Do that a few times and you rapidly end up with lines 300 characters wide. (!) Instead, I prefer

 foo x y z = do    thing1 x    thing2 x y    thing3 z    ...

But, as they say, everybody has their own ideas about style. I think the most important point must surely be that any style is applied *consistently*...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mon, Sep 27, 2010 at 2:09 PM, aditya siram wrote:

How do you guys indent long function arguments? I run into this all the time with the 'maybe' function which takes 3 arguments: maybe :: b -> (a -> b) -> Maybe a -> b I usually end up doing things like (pretend the arguments are aligned if you're not using a monospace font to view this): maybe do-if-Nothing          (\x -> do-if-Just x)          maybe-value This gets a little unwieldly if the any of the arguments stretch over one line like:

maybe do-if-Nothing          (\x -> ...                  ...                  something          )          maybe-value

I do basically like that only I don't try to line up vertically. One indent to continue a line, nested indent for a nested continued line. However, I tend to factor out the long values with let or where. I find it hard to read when everything is coming from some third argument which is a tiny nub at the end of a giant expression. And if you factor out the "if just" case, you can also more easily make the transition to monadic style if you find yourself with too many 'maybe's in sequence. If you can eta-reduce that last arg, though, it can be pretty: defaulted = maybe deflt $ \v -> [ do ] stuff ... One place I do have difficulty is in pattern matching, because you can't factor that out as easily. I do use view patterns sometimes for that, but only when it's a common pattern. So I wind up with a nested indent: function too many arguments with (Complicated (Pattern matching)) = definition case x of Pattern (Match Is Way Too Long) -> stuff It's ugly but rare. 'let' within a 'do' is a particular culprit because right off the bat you've got one indent for 'do' and then the 'let' forces two more indents. Sometimes the too many arguments can be factored into a single type, sometimes nasty nested pattern matches can be factored into view patterns or a data structure that reflects its access pattern rather than building pattern or whatever.

On 30 September 2010 16:47, Roel van Dijk wrote:

On the subject of coding style, I can work with almost any style as long as it is used somewhat consistently. Personally I try to optimize my code for ease of reading because I spend much more time reading code than writing. Aligning stuff vertically makes it easier to spot differences.

Me too. One thing that makes figuring out a code base hard is when the code doesn't have explicit imports. Sometimes I can load the code in GHCi and inspect the symbols manually, sometimes I can't. If the import list explicitly said where stuff came from I wouldn't have to deal with this. Regarding style I've come to believe the best style is one that can be enforced by your software, whatever it is. I don't want to have to think about style.

On Thu, 30 Sep 2010, Bas van Dijk wrote:

On Thu, Sep 30, 2010 at 5:15 PM, Christopher Done wrote:

...

... One thing that makes figuring out a code base hard is when the code doesn't have explicit imports. Sometimes I can load the code in GHCi and inspect the symbols manually, sometimes I can't. If the import list explicitly said where stuff came from I wouldn't have to deal with this.

Indeed. I strictly use this style in all my projects. See the following for example:

http://hackage.haskell.org/packages/archive/usb/0.6.0.1/doc/html/src/System-...

I see it as a service to my readers. In order to find out where a symbol is coming from they only need to scroll up and look it up in the import list. Note that for further convenience I group the imports by package so they don't need to figure out which package exports what module.

It is also necessary when you want x.y.* style version dependencies on packages that follow the package versioning policy. http://www.haskell.org/haskellwiki/Import_modules_properly

Sorry, forgot to reply to all

You also sometimes refactor part of a module to another module, and then you need to copy over all the necessary imports. I tend to copy all my imports over and then remove the ones GHCi tells me aren't necessary. So, one solution to make this automatic copy over all the imports from the current module and then prune.

Perhaps I will attempt some of this on the weekend, as it's the biggest pain I have right now writing Haskell code. I spend a lot of time just maintaining my imports.

Same here, though I use exclusively qualified imports so it's not such a hassle.  But it adds busywork when you start a new module or want to split some code into a new one. The one feature I really like in eclipse is a key you hit to clean up the imports.  It removes the unused ones, and tries to find imports for symbols that aren't in scope.  If there are multiple possibilities, it asks which one.  It even does this automatically when you copy and paste code between files.  I would love something like this for haskell. It's easier in my case because I use exclusively qualified imports and almost always name them as the last component after the dot, so if you parse the source file and find 'M.a' and there's no 'import qualified .. as M' then you just search for 'M' modules.  If I were writing this (and I may take a shot some day), I'd write a standalone program that filters a file, that way it works no matter what editor you use.  And why write it in elisp when you could write it in haskell, and have access to haskell-src?

On Thu, 30 Sep 2010, Bas van Dijk wrote:

I believe UnicodeSyntax and symbols make code easier to read.

If it can be read at all ... your Unicode symbol for '::' isn't shown in my terminal.

On Thu, Sep 30, 2010 at 10:51 PM, Henning Thielemann wrote:

On Thu, 30 Sep 2010, Bas van Dijk wrote:

...

I believe UnicodeSyntax and symbols make code easier to read.

If it can be read at all ... your Unicode symbol for '::' isn't shown in my terminal.

Ah what a bummer! I thought most terminals where capable of showing a wide range of Unicode these days. For what it's worth: '::' shows up correctly in my terminals (Konsole or urxvt with Bitstream Vera Sans Mono font). Bas

On Thu, Sep 30, 2010 at 11:24 PM, Bas van Dijk wrote:

For what it's worth: '::' shows up correctly in my terminals (Konsole or urxvt with Bitstream Vera Sans Mono font).

Turns out that I'm actually using the 'DejaVu Sans Mono' font...