Optimal line length for haskell

Rustom Mody

29 Oct 2012 29 Oct '12

7:50 a.m.

There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi

Attachments:

attachment.html (text/html — 600 bytes)

Show replies by date

Iustin Pop

29 Oct 29 Oct

7:59 a.m.

On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote:

...

There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

For what is worth, in our project (Ganeti) which has a mixed Python/Haskell codebase, we're using the same maximum length (80-but-really-79) in both languages, without any (real) issues. regards, iustin

Rustom Mody

8:05 a.m.

On Mon, Oct 29, 2012 at 5:29 PM, Iustin Pop wrote:

...

...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard

On Mon, Oct 29, 2012 at 05:20:20PM +0530, Rustom Mody wrote: prelude?

...
[Or any other thoughts/opinions :-) ]

For what is worth, in our project (Ganeti) which has a mixed Python/Haskell codebase, we're using the same maximum length (80-but-really-79) in both languages, without any (real) issues.

regards, iustin

Sure! There can hardly be a case that 80 causes any issues. Just that a bit more than 80 can sometimes lead to distinctly more elegant programs. Too much more than 80 can cause issues with readability and/or other tools.

Malcolm Wallace

8:10 a.m.

It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting. Regards, Malcolm On 29 Oct 2012, at 11:50, Rustom Mody wrote:

...

There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

Rustom Mody

8:18 a.m.

On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace wrote:

...

It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting.

Regards, Malcolm

Well that goes to underscore a couple of points: 1. The fixed 80 char width that was inviolable decades ago breaks today on both sides: it may be too low or too high! 2. I guess I dont know how to use blogger very well :-) 3. Are you viewing on a narrow device?

Colin Adams

8:25 a.m.

I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen). I certainly don't use an 80-column limit any more. I use the rule: A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.) And I balance line length with function length. On 29 October 2012 12:18, Rustom Mody wrote:

...

On Mon, Oct 29, 2012 at 5:40 PM, Malcolm Wallace wrote:

...
It is kind of ironic that the wide code examples in the blog post are wrapped at 65 chars by the blog formatting.

Regards, Malcolm

Well that goes to underscore a couple of points: 1. The fixed 80 char width that was inviolable decades ago breaks today on both sides: it may be too low or too high! 2. I guess I dont know how to use blogger very well :-) 3. Are you viewing on a narrow device?

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

Mike Meyer

9:10 a.m.

Colin Adams wrote:

...

I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen).

I certainly don't use an 80-column limit any more. I use the rule:

A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.)

I don't think "similar sized viewport" begins to cover it. If the editor wraps long lines, then the lines will always be visible, no matter how long they are. Of course, lines wrapped around to the beginning of the next line in indented code are really, really ugly, so I'd prefer to avoid that. This is one of the cases where it's more important that there be a standard than what the actual value is. Personally, I like roughly 80 columns, but I've been dong this long enough to have used the things that the 80-column console format was copied from. That screens are now bigger isn't really relevant. They are also windowed - no matter how hard Windows, Linux and Mac apps try and pretend they own the entire screen - and multitasking, so it's unreasonable to format code as if the editor were going to be the only visible window. On the other hand, readable cross-platform text formatting always seems to be a lost cause, as this mail and the referenced blog posting demonstrate. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

Rustom Mody

9:25 a.m.

On Mon, Oct 29, 2012 at 5:55 PM, Colin Adams wrote:

...

I'm not viewing on a narrow device, and I see the wrapped (and the whole post confined to the centre of the screen).

I certainly don't use an 80-column limit any more. I use the rule:

A function must be completely visible in my editor on my screen. (but this is only a good rule if most people who will be reading the code will also have a similar sized viewport. After all, code is far more often read than written.)

And I balance line length with function length.

Very good point: getting the line to fit in one screen-line is of comparable importance to getting a function into one screen. And especially when one is teaching, (as Roman easily figured out!) having to scroll up and down in the midst of explanations is a certain show-spoiler. On Mon, Oct 29, 2012 at 6:40 PM, Mike Meyer wrote:

...

On the other hand, readable cross-platform text formatting always seems to be a lost cause, as this mail and the referenced blog posting demonstrate. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

As for the wraparound problems, hopefully they are now solved (for normal computers!) I'd appreciate hearing if they are not. And Thanks Colin for the debugging support! Clearly prettifying code and prettifying a blog are different issues and putting them together makes a harder constraint-solving problem (especially for a blogger noob!) Rusi

Roman Cheplyaka

8:17 a.m.

* Rustom Mody [2012-10-29 17:20:20+0530]

...

There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

Indeed, I've seen quite a few Haskell projects with long lines. Personally, I find it hard to read and very irritating. I always use 80-chars lines in my projects. It seems that people who write long lines mostly come from academic background, where there's less emphasis on maintainability (no offense; also, I haven't conducted a proper statistical research — this is just an impression). Roman

Michael Orlitzky

9:52 a.m.

On 10/29/2012 07:50 AM, Rustom Mody wrote:

...

There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result. I think the lexer is an example of refactoring-needed rather than long-lines-needed.

Lyndon Maydwell

10:16 a.m.

If I find my line is longer than 80 characters, I just shorten my function and variable names! It's perfectly idio(ma)tic! On Mon, Oct 29, 2012 at 9:52 PM, Michael Orlitzky wrote:

...

On 10/29/2012 07:50 AM, Rustom Mody wrote:

...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result.

I think the lexer is an example of refactoring-needed rather than long-lines-needed.

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

Alexander Solla

10:28 a.m.

On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky wrote:

...

...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard

On 10/29/2012 07:50 AM, Rustom Mody wrote: prelude?

...
[Or any other thoughts/opinions :-) ]

In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result.

I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide "normal form". Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format)

Michael Orlitzky

11:06 a.m.

On 10/29/2012 10:28 AM, Alexander Solla wrote:

...

In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result.

I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide "normal form". Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format)

Well, I did leave the door open for special cases with "usually (but not always)." I know I've had to go over 80 chars before with huge constants or long test names. If you're willing to sacrifice maintain/readability for some other property (e.g. source code sortability), then I don't think my point applies.

Rustom Mody

12:44 p.m.

On Mon, Oct 29, 2012 at 7:58 PM, Alexander Solla wrote:

...

On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky wrote:

...
...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard

On 10/29/2012 07:50 AM, Rustom Mody wrote: prelude?

...
[Or any other thoughts/opinions :-) ]

In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result.

I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide "normal form". Yes, the normal form can sometimes be refactored, but to what end? You might easily end up refactoring out of the level of abstraction you actually want. Or the wide form might have useful properties, like the ability to sort the lines of source code alphanumerically (which would be lost if you switched to a stanza-based format)

Interesting points. In fact my wish for using (when appropriate) a wide form is related to some hunch about this 'wide normal form' Can you throw some light on how one may understand that phraset? Also BTW Ive cleaned up the post again. Since my ineptitude with blogger was looking like an ineptitude with haskell (which may well be there and more :-) ) Ive moved the wide code to gist. I believe the code examples speak differently in this new format Rusi -- http://blog.languager.org

Richard O'Keefe

7:09 p.m.

On 30/10/2012, at 3:28 AM, Alexander Solla wrote:

...

On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky wrote: In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result.

I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide "normal form". Yes, the normal form can sometimes be refactored, but to what end?

Better code? I have no idea of what "a wide normal form" might be, and less idea of why that would imply that a narrower and better form does not also exist. We can argue till everyone is sick and tired and still not reach any kind of consensus. Let's have some *examples*. (For the record, the longest line lengths I've ever seen have been in C++ and Java. I know someone who, and I am not kidding, thinks a 390- column line in code intended to be read by other people is OK.) My own perspective is that if I can't fit it onto one slide in large type for my students to see it is too big.

Alexander Solla

30 Oct 30 Oct

12:56 a.m.

On Mon, Oct 29, 2012 at 4:09 PM, Richard O'Keefe wrote:

...

...
On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky wrote: In any language, a line longer than 80 characters usually (but not always) suggests that you might want to stop and rethink your design. In many cases a refactoring or two will greatly simplify the code and reduce your line length as a result.

I disagree. That might be true for imperative languages, where width is indicative of deep nesting and its associated problems. But it is not true for a functional language, where it is merely indicative of a wide "normal

On 30/10/2012, at 3:28 AM, Alexander Solla wrote: form". Yes, the normal form can sometimes be refactored, but to what end?

Better code? I have no idea of what "a wide normal form" might be, and less idea of why that would imply that a narrower and better form does not also exist.

I made no implication that narrower forms are not useful, or even better, given that the structure is not incompatible with the syntax used to implement it. (For example, I would much rather [1,2,3,4,5] over

...

[1 ,2 ,3 ,4 ,5 ]

but would likely prefer

...

[ "alpha" , "beta" .. , "omega" ]

over the alternative. For example, I generally prefer using the combinators directly when dealing with functors, applicatives, and monads. This can be written "wide", but it can also be written in the style of:

...

f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k)

That is perfectly sensible. But if I had to repeat this syntactic construct, I would probably do it wide:

...

f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k) g' = g <$> (d >>= g) <*> (e >>= h) <*> (f >>= i >>= k)

The new row exposes a sort of "tabular" structure. This code is easy to edit, all at once, highlights differences, and exposes similarities that might be hidden if written in stanza format and have enough "rows" in that format. Of course, a "normal form" merely a combinator, or rather, its definiens. So one might ask, why not factor this out into a combinator? That might well be appropriate, or it might not. Either way, your program end up with a table for values which may vary (since, presumably, the definitions of f' and g' witness that you want to define f' and g'.), as in:

...

f' = comb f a b c g' = comb g d e f

This cannot be made any narrower (up to naming). We can call a normal form n-wide if its combinator requires n arguments. How many combinators do we really want? A combinator is what it will take to factor the "wideness" out of a tabular form, and all you get is a maybe narrower tabular form. My own perspective is that if I can't fit it onto one slide in large

...

type for my students to see it is too big.

This is fair enough, but there are some types of extremely uninteresting code that don't go on slides and are naturally expressed as extremely wide tables. Typically, it is data for use by the program -- the stuff the program traverses to output its answer.

Richard O'Keefe

3:13 a.m.

On 30/10/2012, at 5:56 PM, Alexander Solla wrote:

...

For example, I generally prefer using the combinators directly when dealing with functors, applicatives, and monads. This can be written "wide", but it can also be written in the style of:

...
f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k)

That is perfectly sensible. But if I had to repeat this syntactic construct, I would probably do it wide:

...
f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k) g' = g <$> (d >>= g) <*> (e >>= h) <*> (f >>= i >>= k) 021346789021346789021346789021346789021346789021346789

The new row exposes a sort of "tabular" structure.

The trouble is that this is not real code. As it stands, nobody is complaining about this example. It fits well into 65 columns, being 60 columns wide. I really would like to see real examples. I found the lines of the SegmentTree code that was mentioned recently to be too long for comfort. Line wrapping in TextEdit (or for that matter Emacs) takes no heed whatever of Haskell syntax. I also found that the lines could very easily have been broken in quite natural places.fine f' and g'.), as in:

...

...
f' = comb f a b c g' = comb g d e f

This cannot be made any narrower (up to naming).

Yes, it can. f' = comb f a b c g' = comb g d e f There's an indentation meta-rule that I am very fond of: Where a line is *broken* depends on the spelling of names; where a line is *indented* depends only on logical structure.

...

We can call a normal form n-wide if its combinator requires n arguments.

And they can each go on a separate line if need be.

...

This is fair enough, but there are some types of extremely uninteresting code that don't go on slides and are naturally expressed as extremely wide tables. Typically, it is data for use by the program -- the stuff the program traverses to output its answer.

I have nothing to say about machine-generated code (and if it's _that_ uninteresting, and _that_ naturally expressed by extremely wide tables, then let's hope no human had to suffer to create it).

Evan Laforge

3:32 a.m.

I wonder if people who like one giant window maybe don't use the REPL? I keep 3 windows open: one with the editor, one with ghci, and one with a shell. The shell I use for compiles, darcs records, diffs, grepping, moving files around, etc. I don't understand how people are able work with fewer... it's awkward to constantly ^Z out of the editor, not to mention that you can't look at a diff, test output, compiler output, etc. and code at the same time. With the REPL I'm constantly jumping back and forth to fix type errors, test functions, etc. Since I have 3 terminals that basically means a strict 80 columns on all but the widest monitors, but it's never a problem. Just define more small functions. Breaking them up keeps the nesting down, gives names to to sections, gives me something to test from the REPL, and ensures there are regularly spaced toplevel type signatures, so a type error doesn't propagate too far through inference. I've tried with >3 terminals but I can never figure out what to do with the extra ones. Now that I think of it, it would be interesting to slave two vims together so the secondary one is always the % buffer. Then I don't worry about who is opened where but can still swap between current and last used quickly.

Mike Meyer

6:58 a.m.

Evan Laforge wrote:

...

I wonder if people who like one giant window maybe don't use the REPL? I keep 3 windows open: one with the editor, one with ghci, and one with a shell. [...] I've tried with >3 terminals but I can never figure out what to do with the extra ones.

Besides your two shells, I tend to have a documentation browser should I be using a library I'm not familiar with, and (once the project gets large enough) a second editor window for files with code that might interact with the code I'm working on. Of course, in an IDE (I use emacs), all of these things tend to be available as panes in one window. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

Alexander Solla

10:24 a.m.

On Tue, Oct 30, 2012 at 12:13 AM, Richard O'Keefe wrote:

...

On 30/10/2012, at 5:56 PM, Alexander Solla wrote:

...
For example, I generally prefer using the combinators directly when dealing with functors, applicatives, and monads. This can be written "wide", but it can also be written in the style of:

...
f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k)

That is perfectly sensible. But if I had to repeat this syntactic construct, I would probably do it wide:

...
f' = f <$> (a >>= g) <*> (b >>= h) <*> (c >>= i >>= k) g' = g <$> (d >>= g) <*> (e >>= h) <*> (f >>= i >>= k) 021346789021346789021346789021346789021346789021346789

The new row exposes a sort of "tabular" structure.

The trouble is that this is not real code.

It's real enough. Throw in some sensible naming and we'll probably be near 80 columns. A few long names and we'll be near 90. Throw in another argument to f and we'll have at least another 6 columns. I'm sure plenty of us use the applicative-monad "pattern", even with functions which take a large number of arguments.

...

As it stands, nobody is complaining about this example. It fits well into 65 columns, being 60 columns wide.

I really would like to see real examples.

-- | 'countries_and_iso_country_codes' represents the bijection between 'Country's and -- their 'ISOCountryCode's. countries_and_iso_country_codes :: [ (Country, ISOCountryCode) ] countries_and_iso_country_codes = [ ( Afghanistan , ISOCountryCode AF AFG (isoNumericCode 004) ) , ( AlandIslands , ISOCountryCode AX ALA (isoNumericCode 248) ) , ( Albania , ISOCountryCode AL ALB (isoNumericCode 008) ) , ( Algeria , ISOCountryCode DZ DZA (isoNumericCode 012) ) , ( AmericanSamoa , ISOCountryCode AS ASM (isoNumericCode 016) ) , ( Andorra , ISOCountryCode AD AND (isoNumericCode 020) ) , ( Angola , ISOCountryCode AO AGO (isoNumericCode 024) ) , ( Anguilla , ISOCountryCode AI AIA (isoNumericCode 660) ) , ( Antarctica , ISOCountryCode AQ ATA (isoNumericCode 010) ) , ( AntiguaAndBarbuda , ISOCountryCode AG ATG (isoNumericCode 028) ) , ( Argentina , ISOCountryCode AR ARG (isoNumericCode 032) ) , ( Armenia , ISOCountryCode AM ARM (isoNumericCode 051) ) , ( Aruba , ISOCountryCode AW ABW (isoNumericCode 533) ) , ( Australia , ISOCountryCode AU AUS (isoNumericCode 036) ) , ( Austria , ISOCountryCode AT AUT (isoNumericCode 040) ) , ( Azerbaijan , ISOCountryCode AZ AZE (isoNumericCode 031) ) , ( Bahamas , ISOCountryCode BS BHS (isoNumericCode 044) ) , ( Bahrain , ISOCountryCode BH BHR (isoNumericCode 048) ) , ( Bangladesh , ISOCountryCode BD BGD (isoNumericCode 050) ) , ( Barbados , ISOCountryCode BB BRB (isoNumericCode 052) ) , ( Belarus , ISOCountryCode BY BLR (isoNumericCode 112) ) , ( Belgium , ISOCountryCode BE BEL (isoNumericCode 056) ) , ( Belize , ISOCountryCode BZ BLZ (isoNumericCode 084) ) , ( Benin , ISOCountryCode BJ BEN (isoNumericCode 204) ) , ( Bermuda , ISOCountryCode BM BMU (isoNumericCode 060) ) , ( Bhutan , ISOCountryCode BT BTN (isoNumericCode 064) ) , ( Bolivia , ISOCountryCode BO BOL (isoNumericCode 068) ) , ( BosniaAndHerzegovina , ISOCountryCode BA BIH (isoNumericCode 070) ) , ( Botswana , ISOCountryCode BW BWA (isoNumericCode 072) ) , ( BouvetIsland , ISOCountryCode BV BVT (isoNumericCode 074) ) , ( Brazil , ISOCountryCode BR BRA (isoNumericCode 076) ) , ( BritishIndianOceanTerritory , ISOCountryCode IO IOT (isoNumericCode 086) ) , ( BruneiDarussalam , ISOCountryCode BN BRN (isoNumericCode 096) ) , ( Bulgaria , ISOCountryCode BG BGR (isoNumericCode 100) ) , ( BurkinaFaso , ISOCountryCode BF BFA (isoNumericCode 854) ) , ( Burundi , ISOCountryCode BI BDI (isoNumericCode 108) ) , ( Cambodia , ISOCountryCode KH KHM (isoNumericCode 116) ) , ( Cameroon , ISOCountryCode CM CMR (isoNumericCode 120) ) , ( Canada , ISOCountryCode CA CAN (isoNumericCode 124) ) , ( CapeVerde , ISOCountryCode CV CPV (isoNumericCode 132) ) , ( CaymanIslands , ISOCountryCode KY CYM (isoNumericCode 136) ) , ( CentralAfricanRepublic , ISOCountryCode CF CAF (isoNumericCode 140) ) , ( Chad , ISOCountryCode TD TCD (isoNumericCode 148) ) , ( Chile , ISOCountryCode CL CHL (isoNumericCode 152) ) , ( China , ISOCountryCode CN CHN (isoNumericCode 156) ) , ( ChristmasIsland , ISOCountryCode CX CXR (isoNumericCode 162) ) , ( CocosKeelingIslands , ISOCountryCode CC CCK (isoNumericCode 166) ) , ( Colombia , ISOCountryCode CO COL (isoNumericCode 170) ) , ( Comoros , ISOCountryCode KM COM (isoNumericCode 174) ) , ( Congo , ISOCountryCode CG COG (isoNumericCode 178) ) , ( DemocraticRepublicOfCongo , ISOCountryCode CD COD (isoNumericCode 180) ) , ( CookIslands , ISOCountryCode CK COK (isoNumericCode 184) ) , ( CostaRica , ISOCountryCode CR CRI (isoNumericCode 188) ) , ( CoteDIvoire , ISOCountryCode CI CIV (isoNumericCode 384) ) , ( Croatia , ISOCountryCode HR HRV (isoNumericCode 191) ) , ( Cuba , ISOCountryCode CU CUB (isoNumericCode 192) ) , ( Cyprus , ISOCountryCode CY CYP (isoNumericCode 196) ) , ( CzechRepublic , ISOCountryCode CZ CZE (isoNumericCode 203) ) , ( Denmark , ISOCountryCode DK DNK (isoNumericCode 208) ) , ( Djibouti , ISOCountryCode DJ DJI (isoNumericCode 262) ) , ( Dominica , ISOCountryCode DM DMA (isoNumericCode 212) ) , ( DominicanRepublic , ISOCountryCode DO DOM (isoNumericCode 214) ) , ( Ecuador , ISOCountryCode EC ECU (isoNumericCode 218) ) , ( Egypt , ISOCountryCode EG EGY (isoNumericCode 818) ) , ( ElSalvador , ISOCountryCode SV SLV (isoNumericCode 222) ) , ( EquatorialGuinea , ISOCountryCode GQ GNQ (isoNumericCode 226) ) , ( Eritrea , ISOCountryCode ER ERI (isoNumericCode 232) ) , ( Estonia , ISOCountryCode EE EST (isoNumericCode 233) ) , ( Ethiopia , ISOCountryCode ET ETH (isoNumericCode 231) ) , ( FalklandIslands , ISOCountryCode FK FLK (isoNumericCode 238) ) , ( FaroeIslands , ISOCountryCode FO FRO (isoNumericCode 234) ) , ( Fiji , ISOCountryCode FJ FJI (isoNumericCode 242) ) , ( Finland , ISOCountryCode FI FIN (isoNumericCode 246) ) , ( France , ISOCountryCode FR FRA (isoNumericCode 250) ) , ( FrenchGuiana , ISOCountryCode GF GUF (isoNumericCode 254) ) , ( FrenchPolynesia , ISOCountryCode PF PYF (isoNumericCode 258) ) , ( FrenchSouthernTerritories , ISOCountryCode TF ATF (isoNumericCode 260) ) , ( Gabon , ISOCountryCode GA GAB (isoNumericCode 266) ) , ( Gambia , ISOCountryCode GM GMB (isoNumericCode 270) ) , ( Georgia , ISOCountryCode GE GEO (isoNumericCode 268) ) , ( Germany , ISOCountryCode DE DEU (isoNumericCode 276) ) , ( Ghana , ISOCountryCode GH GHA (isoNumericCode 288) ) , ( Gibraltar , ISOCountryCode GI GIB (isoNumericCode 292) ) , ( Greece , ISOCountryCode GR GRC (isoNumericCode 300) ) , ( Greenland , ISOCountryCode GL GRL (isoNumericCode 304) ) , ( Grenada , ISOCountryCode GD GRD (isoNumericCode 308) ) , ( Guadeloupe , ISOCountryCode GP GLP (isoNumericCode 312) ) , ( Guam , ISOCountryCode GU GUM (isoNumericCode 316) ) , ( Guatemala , ISOCountryCode GT GTM (isoNumericCode 320) ) , ( Guernsey , ISOCountryCode GG GGY (isoNumericCode 831) ) , ( Guinea , ISOCountryCode GN GIN (isoNumericCode 324) ) , ( GuineaBissau , ISOCountryCode GW GNB (isoNumericCode 624) ) , ( Guyana , ISOCountryCode GY GUY (isoNumericCode 328) ) , ( Haiti , ISOCountryCode HT HTI (isoNumericCode 332) ) , ( HeardIslandAndMcDonaldIslands , ISOCountryCode HM HMD (isoNumericCode 334) ) , ( HolySee , ISOCountryCode VA VAT (isoNumericCode 336) ) , ( Honduras , ISOCountryCode HN HND (isoNumericCode 340) ) , ( HongKong , ISOCountryCode HK HKG (isoNumericCode 344) ) , ( Hungary , ISOCountryCode HU HUN (isoNumericCode 348) ) , ( Iceland , ISOCountryCode IS ISL (isoNumericCode 352) ) , ( India , ISOCountryCode IN IND (isoNumericCode 356) ) , ( Indonesia , ISOCountryCode ID IDN (isoNumericCode 360) ) , ( Iran , ISOCountryCode IR IRN (isoNumericCode 364) ) , ( Iraq , ISOCountryCode IQ IRQ (isoNumericCode 368) ) , ( Ireland , ISOCountryCode IE IRL (isoNumericCode 372) ) , ( IsleOfMan , ISOCountryCode IM IMN (isoNumericCode 833) ) , ( Israel , ISOCountryCode IL ISR (isoNumericCode 376) ) , ( Italy , ISOCountryCode IT ITA (isoNumericCode 380) ) , ( Jamaica , ISOCountryCode JM JAM (isoNumericCode 388) ) , ( Japan , ISOCountryCode JP JPN (isoNumericCode 392) ) , ( Jersey , ISOCountryCode JE JEY (isoNumericCode 832) ) , ( Jordan , ISOCountryCode JO JOR (isoNumericCode 400) ) , ( Kazakhstan , ISOCountryCode KZ KAZ (isoNumericCode 398) ) , ( Kenya , ISOCountryCode KE KEN (isoNumericCode 404) ) , ( Kiribati , ISOCountryCode KI KIR (isoNumericCode 296) ) , ( NorthKorea , ISOCountryCode KP PRK (isoNumericCode 408) ) , ( SouthKorea , ISOCountryCode KR KOR (isoNumericCode 410) ) , ( Kuwait , ISOCountryCode KW KWT (isoNumericCode 414) ) , ( Kyrgyzstan , ISOCountryCode KG KGZ (isoNumericCode 417) ) , ( Laos , ISOCountryCode LA LAO (isoNumericCode 418) ) , ( Latvia , ISOCountryCode LV LVA (isoNumericCode 428) ) , ( Lebanon , ISOCountryCode LB LBN (isoNumericCode 422) ) , ( Lesotho , ISOCountryCode LS LSO (isoNumericCode 426) ) , ( Liberia , ISOCountryCode LR LBR (isoNumericCode 430) ) , ( Libya , ISOCountryCode LY LBY (isoNumericCode 434) ) , ( Liechtenstein , ISOCountryCode LI LIE (isoNumericCode 438) ) , ( Lithuania , ISOCountryCode LT LTU (isoNumericCode 440) ) , ( Luxembourg , ISOCountryCode LU LUX (isoNumericCode 442) ) , ( Macao , ISOCountryCode MO MAC (isoNumericCode 446) ) , ( Macedonia , ISOCountryCode MK MKD (isoNumericCode 807) ) , ( Madagascar , ISOCountryCode MG MDG (isoNumericCode 450) ) , ( Malawi , ISOCountryCode MW MWI (isoNumericCode 454) ) , ( Malaysia , ISOCountryCode MY MYS (isoNumericCode 458) ) , ( Maldives , ISOCountryCode MV MDV (isoNumericCode 462) ) , ( Mali , ISOCountryCode ML MLI (isoNumericCode 466) ) , ( Malta , ISOCountryCode MT MLT (isoNumericCode 470) ) , ( MarshallIslands , ISOCountryCode MH MHL (isoNumericCode 584) ) , ( Martinique , ISOCountryCode MQ MTQ (isoNumericCode 474) ) , ( Mauritania , ISOCountryCode MR MRT (isoNumericCode 478) ) , ( Mauritius , ISOCountryCode MU MUS (isoNumericCode 480) ) , ( Mayotte , ISOCountryCode YT MYT (isoNumericCode 175) ) , ( Mexico , ISOCountryCode MX MEX (isoNumericCode 484) ) , ( Micronesia , ISOCountryCode FM FSM (isoNumericCode 583) ) , ( Moldova , ISOCountryCode MD MDA (isoNumericCode 498) ) , ( Monaco , ISOCountryCode MC MCO (isoNumericCode 492) ) , ( Mongolia , ISOCountryCode MN MNG (isoNumericCode 496) ) , ( Montenegro , ISOCountryCode ME MNE (isoNumericCode 499) ) , ( Montserrat , ISOCountryCode MS MSR (isoNumericCode 500) ) , ( Morocco , ISOCountryCode MA MAR (isoNumericCode 504) ) , ( Mozambique , ISOCountryCode MZ MOZ (isoNumericCode 508) ) , ( Myanmar , ISOCountryCode MM MMR (isoNumericCode 104) ) , ( Namibia , ISOCountryCode NA NAM (isoNumericCode 516) ) , ( Nauru , ISOCountryCode NR NRU (isoNumericCode 520) ) , ( Nepal , ISOCountryCode NP NPL (isoNumericCode 524) ) , ( Netherlands , ISOCountryCode NL NLD (isoNumericCode 528) ) , ( NetherlandsAntilles , ISOCountryCode AN ANT (isoNumericCode 530) ) , ( NewCaledonia , ISOCountryCode NC NCL (isoNumericCode 540) ) , ( NewZealand , ISOCountryCode NZ NZL (isoNumericCode 554) ) , ( Nicaragua , ISOCountryCode NI NIC (isoNumericCode 558) ) , ( Niger , ISOCountryCode NE NER (isoNumericCode 562) ) , ( Nigeria , ISOCountryCode NG NGA (isoNumericCode 566) ) , ( Niue , ISOCountryCode NU NIU (isoNumericCode 570) ) , ( NorfolkIsland , ISOCountryCode NF NFK (isoNumericCode 574) ) , ( NorthernMarianaIslands , ISOCountryCode MP MNP (isoNumericCode 580) ) , ( Norway , ISOCountryCode NO NOR (isoNumericCode 578) ) , ( Oman , ISOCountryCode OM OMN (isoNumericCode 512) ) , ( Pakistan , ISOCountryCode PK PAK (isoNumericCode 586) ) , ( Palau , ISOCountryCode PW PLW (isoNumericCode 585) ) , ( Palestinine , ISOCountryCode PS PSE (isoNumericCode 275) ) , ( Panama , ISOCountryCode PA PAN (isoNumericCode 591) ) , ( PapuaNewGuinea , ISOCountryCode PG PNG (isoNumericCode 598) ) , ( Paraguay , ISOCountryCode PY PRY (isoNumericCode 600) ) , ( Peru , ISOCountryCode PE PER (isoNumericCode 604) ) , ( Philippines , ISOCountryCode PH PHL (isoNumericCode 608) ) , ( Pitcairn , ISOCountryCode PN PCN (isoNumericCode 612) ) , ( Poland , ISOCountryCode PL POL (isoNumericCode 616) ) , ( Portugal , ISOCountryCode PT PRT (isoNumericCode 620) ) , ( PuertoRico , ISOCountryCode PR PRI (isoNumericCode 630) ) , ( Qatar , ISOCountryCode QA QAT (isoNumericCode 634) ) , ( Reunion , ISOCountryCode RE REU (isoNumericCode 638) ) , ( Romania , ISOCountryCode RO ROU (isoNumericCode 642) ) , ( RussianFederation , ISOCountryCode RU RUS (isoNumericCode 643) ) , ( Rwanda , ISOCountryCode RW RWA (isoNumericCode 646) ) , ( SaintBarthelemy , ISOCountryCode BL BLM (isoNumericCode 652) ) , ( SaintHelenaAscensionAndTristanDaCunha , ISOCountryCode SH SHN (isoNumericCode 654) ) , ( SaintKittsAndNevis , ISOCountryCode KN KNA (isoNumericCode 659) ) , ( SaintLucia , ISOCountryCode LC LCA (isoNumericCode 662) ) , ( SaintMartin , ISOCountryCode MF MAF (isoNumericCode 663) ) , ( SaintPierreAndMiquelon , ISOCountryCode PM SPM (isoNumericCode 666) ) , ( SaintVincentAndTheGrenadines , ISOCountryCode VC VCT (isoNumericCode 670) ) , ( Samoa , ISOCountryCode WS WSM (isoNumericCode 882) ) , ( SanMarino , ISOCountryCode SM SMR (isoNumericCode 674) ) , ( SaoTomeAndPrincipe , ISOCountryCode ST STP (isoNumericCode 678) ) , ( SaudiArabia , ISOCountryCode SA SAU (isoNumericCode 682) ) , ( Senegal , ISOCountryCode SN SEN (isoNumericCode 686) ) , ( Serbia , ISOCountryCode RS SRB (isoNumericCode 688) ) , ( Seychelles , ISOCountryCode SC SYC (isoNumericCode 690) ) , ( SierraLeone , ISOCountryCode SL SLE (isoNumericCode 694) ) , ( Singapore , ISOCountryCode SG SGP (isoNumericCode 702) ) , ( Slovakia , ISOCountryCode SK SVK (isoNumericCode 703) ) , ( Slovenia , ISOCountryCode SI SVN (isoNumericCode 705) ) , ( SolomonIslands , ISOCountryCode SB SLB (isoNumericCode 090) ) , ( Somalia , ISOCountryCode SO SOM (isoNumericCode 706) ) , ( SouthAfrica , ISOCountryCode ZA ZAF (isoNumericCode 710) ) , ( SouthGeorgiaAndtheSouthSandwichIslands , ISOCountryCode GS SGS (isoNumericCode 239) ) , ( Spain , ISOCountryCode ES ESP (isoNumericCode 724) ) , ( SriLanka , ISOCountryCode LK LKA (isoNumericCode 144) ) , ( Sudan , ISOCountryCode SD SDN (isoNumericCode 736) ) , ( Suriname , ISOCountryCode SR SUR (isoNumericCode 740) ) , ( SvalbardAndJanMayen , ISOCountryCode SJ SJM (isoNumericCode 744) ) , ( Swaziland , ISOCountryCode SZ SWZ (isoNumericCode 748) ) , ( Sweden , ISOCountryCode SE SWE (isoNumericCode 752) ) , ( Switzerland , ISOCountryCode CH CHE (isoNumericCode 756) ) , ( Syria , ISOCountryCode SY SYR (isoNumericCode 760) ) , ( Taiwan , ISOCountryCode TW TWN (isoNumericCode 158) ) , ( Tajikistan , ISOCountryCode TJ TJK (isoNumericCode 762) ) , ( Tanzania , ISOCountryCode TZ TZA (isoNumericCode 834) ) , ( Thailand , ISOCountryCode TH THA (isoNumericCode 764) ) , ( TimorLeste , ISOCountryCode TL TLS (isoNumericCode 626) ) , ( Togo , ISOCountryCode TG TGO (isoNumericCode 768) ) , ( Tokelau , ISOCountryCode TK TKL (isoNumericCode 772) ) , ( Tonga , ISOCountryCode TO TON (isoNumericCode 776) ) , ( TrinidadAndTobago , ISOCountryCode TT TTO (isoNumericCode 780) ) , ( Tunisia , ISOCountryCode TN TUN (isoNumericCode 788) ) , ( Turkey , ISOCountryCode TR TUR (isoNumericCode 792) ) , ( Turkmenistan , ISOCountryCode TM TKM (isoNumericCode 795) ) , ( TurksAndCaicosIslands , ISOCountryCode TC TCA (isoNumericCode 796) ) , ( Tuvalu , ISOCountryCode TV TUV (isoNumericCode 798) ) , ( Uganda , ISOCountryCode UG UGA (isoNumericCode 800) ) , ( Ukraine , ISOCountryCode UA UKR (isoNumericCode 804) ) , ( UnitedArabEmirates , ISOCountryCode AE ARE (isoNumericCode 784) ) , ( UnitedKingdom , ISOCountryCode GB GBR (isoNumericCode 826) ) , ( UnitedStates , ISOCountryCode US USA (isoNumericCode 840) ) , ( UnitedStatesMinorOutlyingIslands , ISOCountryCode UM UMI (isoNumericCode 581) ) , ( Uruguay , ISOCountryCode UY URY (isoNumericCode 858) ) , ( Uzbekistan , ISOCountryCode UZ UZB (isoNumericCode 860) ) , ( Vanuatu , ISOCountryCode VU VUT (isoNumericCode 548) ) , ( Venezuela , ISOCountryCode VE VEN (isoNumericCode 862) ) , ( VietNam , ISOCountryCode VN VNM (isoNumericCode 704) ) , ( BritishVirginIslands , ISOCountryCode VG VGB (isoNumericCode 092) ) , ( USVirginIslands , ISOCountryCode VI VIR (isoNumericCode 850) ) , ( WallisAndFutuna , ISOCountryCode WF WLF (isoNumericCode 876) ) , ( WesternSahara , ISOCountryCode EH ESH (isoNumericCode 732) ) , ( Yemen , ISOCountryCode YE YEM (isoNumericCode 887) ) , ( Zambia , ISOCountryCode ZM ZMB (isoNumericCode 894) ) , ( Zimbabwe , ISOCountryCode ZW ZWE (isoNumericCode 716) ) ]

...

Jake McArthur

29 Oct 29 Oct

10:37 a.m.

I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody wrote:

...

There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

Thanks, Rusi

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

MightyByte

11:32 a.m.

I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file. "The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text." Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97. On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur wrote:

...

I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :)

I don't think long lines indicate a design problem; it's solely a formatting thing.

On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody wrote:

...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ]

Thanks, Rusi

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

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

Niklas Hambüchen

11:50 a.m.

I would prefer to completely ignore line lengths when writing Haskell. In general, giving good names to things in where-clauses automatically keeps my code "short enough". My opinion is that different people like different code layouts, and when formatting code in certain ways, we will always have to make compromises. I would like if there was a layout normal form for storing Haskell code - all code presented to humans should be shown just as that human likes it best. In the future, I would like to work on a personalizable real-time formatter that editors can hook into, using haskell-src-exts.

Iustin Pop

11:57 a.m.

On Mon, Oct 29, 2012 at 03:50:57PM +0000, Niklas Hambüchen wrote:

...

I would prefer to completely ignore line lengths when writing Haskell.

In general, giving good names to things in where-clauses automatically keeps my code "short enough".

My opinion is that different people like different code layouts, and when formatting code in certain ways, we will always have to make compromises.

I would like if there was a layout normal form for storing Haskell code - all code presented to humans should be shown just as that human likes it best.

In the future, I would like to work on a personalizable real-time formatter that editors can hook into, using haskell-src-exts.

+1 to that; I know that it would indeed increase my productivity… iustin

Marc Ziegert

4:44 p.m.

O_o Those are damn strange reasons to restrict oneself to 80 chars, iMho. I tend to look at ONE file at a time, on one fullscreen widescreen. 100 chars per line is more or less normal; I have my vertical line limit marker set to 100, but only for layout-zen. My lines have sometimes 200 chars length, which causes the less important (long) code not to clutter my overview on the >50 neighbouring lines (~10 functions overview on the left half of the screen). Otherwise, I'd use a browser/Haddock on one part of the screen just to see an overview of the code I'm writing. I'm now wondering, whether this could have sth to do with my ADD, which I had the first 3 decades of my life (and without whiteboard). I think, I should try to code in a small narrow window of 1/4 of my screen, just to test whether that would (still) be a handicap. Roman: "academic background"... Funny; my impression about this matter was from the other point of view: Short lines are good for diff/patch files. Are there more people here with ADD (or ADD-history) and long-lines-disorder? Or is that just me? - marc -------- Original-Nachricht --------

...

Datum: Mon, 29 Oct 2012 11:32:29 -0400 Von: MightyByte An: Jake McArthur CC: Haskell Cafe Betreff: Re: [Haskell-cafe] Optimal line length for haskell

...

I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file.

"The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text." Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97.

...
I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :)

I don't think long lines indicate a design problem; it's solely a formatting thing.

On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody wrote:

...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard

On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur wrote: prelude?

...
...
[Or any other thoughts/opinions :-) ]

Thanks, Rusi

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

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

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

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (in deutsch: http://www.gerstbach.at/2004/ascii/)

MightyByte

5:27 p.m.

I frequently find myself wanting to look at one file while coding in another file so I can see type signatures, data type definitions, etc. If I only have one file fullscreen, then I would have to switch back and forth to refresh my mind with API information. If your max lines are sometimes 200 chars, then you're going to have tons of wasted screen space from all the other lines that aren't 200 characters wide. On Mon, Oct 29, 2012 at 4:44 PM, Marc Ziegert wrote:

...

O_o Those are damn strange reasons to restrict oneself to 80 chars, iMho.

I tend to look at ONE file at a time, on one fullscreen widescreen. 100 chars per line is more or less normal; I have my vertical line limit marker set to 100, but only for layout-zen. My lines have sometimes 200 chars length, which causes the less important (long) code not to clutter my overview on the >50 neighbouring lines (~10 functions overview on the left half of the screen). Otherwise, I'd use a browser/Haddock on one part of the screen just to see an overview of the code I'm writing.

I'm now wondering, whether this could have sth to do with my ADD, which I had the first 3 decades of my life (and without whiteboard). I think, I should try to code in a small narrow window of 1/4 of my screen, just to test whether that would (still) be a handicap.

Roman: "academic background"... Funny; my impression about this matter was from the other point of view: Short lines are good for diff/patch files.

Are there more people here with ADD (or ADD-history) and long-lines-disorder? Or is that just me?

- marc

-------- Original-Nachricht --------

...
Datum: Mon, 29 Oct 2012 11:32:29 -0400 Von: MightyByte An: Jake McArthur CC: Haskell Cafe Betreff: Re: [Haskell-cafe] Optimal line length for haskell

...
I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file.

"The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text." Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97.

...
I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :)

I don't think long lines indicate a design problem; it's solely a formatting thing.

On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody wrote:

...
There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html.

Are there more striking examples than the lexer from the standard

On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur wrote: prelude?

...
...
[Or any other thoughts/opinions :-) ]

Thanks, Rusi

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

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

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

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (in deutsch: http://www.gerstbach.at/2004/ascii/)

Jason Dusek

30 Oct 30 Oct

4:30 p.m.

2012/10/29 MightyByte :

...

"The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text." Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97.

Robert Bringhurst's "The Elements of Typographic Style" offers a similar dictum: Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple column work, a better average is 40 to 50 characters. -- http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/ I have come to accept 80 characters as a limit that is both in keeping with programming convention and amenable to the good taste of typographers. Many respectable software projects honor this limit and to emulate them, in matters small as well as large, is to simplify our work in many small ways. Art is long and life is short. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

4586

Age (days ago)

4587

Last active (days ago)

List overview

Download

26 comments

16 participants

participants (16)

Alexander Solla
Colin Adams
Evan Laforge
Iustin Pop
Jake McArthur
Jason Dusek
Lyndon Maydwell
Malcolm Wallace
Marc Ziegert
Michael Orlitzky
MightyByte
Mike Meyer
Niklas Hambüchen
Richard O'Keefe
Roman Cheplyaka
Rustom Mody