Dusan Kolar writes:

Dear all,

reading that

...

according the several style guides, lines shouldn't be too long (longer than 78 characters).

http://www.cs.caltech.edu/courses/cs11/material/haskell/misc/haskell_style_g... http://www.haskell.org/haskellwiki/Programming_guidelines

I would like to know, whether 78 characters bound still makes a sense... Even if I connect to my linux box with text terminal, it is not a 80x24 characters HW text terminal, but a window emulating this in whatever else OS, thus, I can usually extend this to see longer lines easily.

Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other?

I believe it is a good practice too keep each line short and easy to read. The following is taken from python style guide. Maximum Line Length Limit all lines to a maximum of 79 characters. There are still many devices around that are limited to 80 character lines; plus, limiting windows to 80 characters makes it possible to have several windows side-by-side. The default wrapping on such devices disrupts the visual structure of the code, making it more difficult to understand. Therefore, please limit all lines to a maximum of 79 characters. For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. http://www.python.org/dev/peps/pep-0008/ P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? -- c/* __o/* <\ * (__ */\ <

On Tue, 2009-04-21 at 13:52 +0100, Neil Mitchell wrote:

...

P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP?

We have one: urchin.earth.li/~ian/style/haskell.html

Yes, it's good. We should publicise it more. Duncan

Maurí­cio wrote:

...

...

We have one: urchin.earth.li/~ian/style/haskell.html

Yes, it's good. We should publicise it more.

Just a tought: I would like to see a guide talking about the code itself, not about the presentation. Maybe this is ignored because it's difficult. It's easy to get bad code and make sure it follows strict layout, doesn't resemble imperative code and has comments on all functions. It's still bad code.

You've nailed it: "this is ignored because it's difficult." It's nothing special about Haskell, it holds for style guides for every language I've seen. It's difficult because it's not a question of science, but rather a question of aesthetics. And as anyone in the humanities can tell you, when it comes to aesthetics people disagree. But the reason they disagree is because of this fundamental truth: there's no right answer. There are many wrong answers, to be sure, but there's no right answer. To put a finer point on it, not everyone likes the same authors. One person's clear discussion is another's pedantry or another's logorrhea. Consider style guides for writing prose. Many of these are full of discussion about where to place commas, or when to use a different word because of the possibility for confusion, or when to reorder the parts of a sentence. What few of them ever discuss are things like how to structure an argument, how to introduce characters, when a character should be removed, what makes for an interesting plot, etc. Even those that discuss such things are typically vague about it and often make appeals to intuitions and aesthetics they presuppose. Good writers and good coders will learn these things over time but they learn them by practice just like any artisan. Good style guides are like a good instructor: they can teach you how to use a chisel, but they can't teach you how to carve. Over time, with enough experience after carving many different things, the good sculptor will come to an intuitive understanding about what things will work and what things are likely to be problematic. They can pass down the lessons, the horror stories, a codification of their hunches, but what they can't teach is the intuition itself. Don't get me wrong, I'd love to see more guides that take on these sorts of issues. This is why they're so rare, is all. My job over the last year has been trying to teach a group of colleagues ---in person--- about what makes good style. In addition to the issues mentioned above, there's another one that looms large. Most people already have a style ---good, bad, indifferent--- and they often perceive any attempts to change that style as (at best) a frivolity or (at worst) an attack on their abilities. Books and webpages can circumvent this to an extent (thanks to the selection bias of who would be reading them anyways), but any guide that is too challenging will be thrown out, no matter how right it is. Thus it takes someone who's a good writer, speaker, or manager and not just someone who's a good coder. Because the author needs to convey not only the intuition, but also enough of themselves that the reader will accept their experience and listen to what they have to say. (And folks who are good with both personal and technical arenas can earn a lot more elsewhere than writing guides, so they'd have to be charitable and generous as well ;) -- Live well, ~wren

2009/04/23 Maurí­cio :

Maybe we could learn with them: what about if Haskell Weekly News had a section on code review, like many newspapers have book review sections?

This seems worthwhile. -- Jason Dusek

On Thu, Apr 23, 2009 at 8:29 PM, Achim Schneider wrote:

Maurí­cio wrote:

...

Maybe we could learn with them: what about if Haskell Weekly News had a section on code review, like many newspapers have book review sections?

The weekly WTF?

I'm not sure such a thing is good... At the very least, such reviews should be anonymous, especially if we're going to cover bad code instead of good. Here's my contribution: I was cabalizing a package once, and I chucked into the build-depends 'ghc' and made it build. About 30 seconds later, it occurred to me that this was a geometry library and what the heck was it doing with the GHC API? So I go looking, and I find a module of utility functions. It's importing GHC.Base. I remove the import and scroll down to see the error. It turns out that 20 megabytes of GHC code was being linked into this program for one function. I took the quick way out and typed into the module: 'isJust Nothing = False; isJust (Just a) = True'. -- gwern

Xiao-Yong Jin wrote:

Gwern Branwen writes:

...

I was cabalizing a package once, and I chucked into the build-depends 'ghc' and made it build. About 30 seconds later, it occurred to me that this was a geometry library and what the heck was it doing with the GHC API? So I go looking, and I find a module of utility functions. It's importing GHC.Base. I remove the import and scroll down to see the error.

It turns out that 20 megabytes of GHC code was being linked into this program for one function. I took the quick way out and typed into the module: 'isJust Nothing = False; isJust (Just a) = True'.

Probably I'm missing something, but why didn't you just import Data.Maybe? I believe both 'isJust' and 'isNothing' is defined in the module.

...and that's TRWTF. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

...

...

Maybe we could learn with them: what about if Haskell Weekly News had a section on code review, like many newspapers have book review sections?

I'm not sure such a thing is good... At the very least, such reviews should be anonymous, especially if we're going to cover bad code instead of good. Here's my contribution:

One important thing about reviews is that (as book reviews) they have to be deep. Maybe, along the lines of what you sugested, you could check, say, 30 or 40 packages in hackage and try to show cases where a package could be a lot more usefull (or have code that is better to read) with a few dependencies less, and show well written examples on how this could be acomplished. Other sugestion: you can read some code you don't know yet but you are interested in, and try to follow what happens in your mind from the time you start until the time you fully understand it. Then you could write sugestion on how the code could be changed so that your mind would have been guided better. Then ask someone to read your knew code, and if you actually made it easier to read, write about your thoughts about the code. Thanks for your sugestion. Best, Maurício

Xiao-Yong Jin schrieb:

P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP?

http://www.haskell.org/haskellwiki/Category:Proposals

The longer a line the more difficult it is to move the focus to the beginning of the next line when reading.

Hmm, then I must be doing something wrong, I do not fully fill program lines... ;-) Or my comments are too short. I do not think, this is an issue, to catch the next line, if the program text is well structured... Nevertheless, I do understand this is a force to make the text structured...

Therefore wide news papers use columns. Also consider source code printed on paper.

I do not remember when I did that. But if anybody does then it is a reason.

...

Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other?

Unlimited length (as for plain text) would be an option if automatic wrapping wouldn't destroy the layout.

Yes, yes... Anyway, I don't like 1024 characters one-liners anyway. ;-) :-) Dušan

I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. It seems silly _25 years later_ to still not be able to have even that much breathing room. Shorter lengths work very poorly in languages like C# with long LINQ queries, you tend to have verbose enough member and method names that you obtain some pretty ridiculous splits. You wind up with some similar scenarios with list compehensions in Haskell. I'm not saying that every line should be 130+ characters long, I'm just saying that 132 characters seems like a more natural hard cut off point. -Edward Kmett On Tue, Apr 21, 2009 at 10:53 AM, Richard Kelsall wrote:

Dusan Kolar wrote: ...

...

Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other?

... As a little historical detour I think the 80 character limit goes back to 1928 when IBM designed their punched card format

http://en.wikipedia.org/wiki/Punched_card#IBM_80_column_punch_card_format

I guess it subsequently got embedded into printing and screen widths and related software. The slightly less than 80 characters allows for CR LF characters.

Richard.

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

Xiao-Yong Jin wrote:

Edward Kmett writes:

...

I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so.  

I prefer 3 coding windows side by side. And being able to read one line at a glance is a huge advantage. The size of my urxvt is 80x77 FYI.

But the discussion is about a coding standard -- surely if I claimed to like to have 4 windows side by side, that wouldn't be a good reason to reduce the standard to 40 columns? Being able to read one line 'at a glance' seems to me to be improved if that line contains the complete equation, rather than just a fragment. Comprehension of a group of related equations can be improved if they all fit on one screen (vertically). Some code that I've written is intended to look like (and function as) rewrite rules and looks vastly better with pattern and replacement all on the same line. All the arguments can cut both ways -- for those who like coding with windows side by side, what about those who like coding with one window above another? Coding style is very situational, but the 80 character standard came about due to a once-ubiquitous device limitation (which no longer exists). The *real* purpose of a coding standard, of course, is to give people something to argue over when they could be actually doing something more productive. So in the end, it's all good, I suppose.

Robert Greayer wrote:

But the discussion is about a coding standard -- surely if I claimed to like to have 4 windows side by side, that wouldn't be a good reason to reduce the standard to 40 columns? Being able to read one line 'at a glance' seems to me to be improved if that line contains the complete equation, rather than just a fragment. Comprehension of a group of related equations can be improved if they all fit on one screen (vertically). Some code that I've written is intended to look like (and function as) rewrite rules and looks vastly better with pattern and replacement all on the same line. All the arguments can cut both ways -- for those who like coding with windows side by side, what about those who like coding with one window above another? Coding style is very situational, but the 80 character standard came about due to a once-ubiquitous device limitation (which no longer exists).

The *real* purpose of a coding standard, of course, is to give people something to argue over when they could be actually doing something more productive. So in the end, it's all good, I suppose.

80 characters may be the device limitation from long ago, but there are other reasons to keep lines from getting too long, as have been mentioned... the ease of reading vertically, the common use of 80-char windows that can be fit side-by-side. As far as arguments "cutting both ways," I think it's really a Goldilocks question. Some code has lines that are clearly too long to be practical (because they will look ugly as they wrap on most people's editors), and 40 characters is clearly too short. Somewhere in the middle is "just right." Now, we may disagree on what "just right" is, but I just want to establish that the various arguments for longer or shorter lines can be regarded as forces that tug the coding standard in one direction or the other, and I think it's valuable to look for the equilibrium. I think 80 characters is a decent compromise. 80-character windows seem to be very common. At work everyone uses them, and as monitors got wider, they put windows side-by-side. Seems like a common practice. Mike

Hi, i hate those html forms that show you [haskell,python] code in a narrow box that is suposed to make the code clear, but it darkens the code by cutting it. Maybe having all lines shorter helps, but the "narrow window" effect is chasing us nonsensely.- haroldo 2009/4/21 Richard Kelsall

Dusan Kolar wrote: ...

...

Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other?

... As a little historical detour I think the 80 character limit goes back to 1928 when IBM designed their punched card format

http://en.wikipedia.org/wiki/Punched_card#IBM_80_column_punch_card_format

I guess it subsequently got embedded into printing and screen widths and related software. The slightly less than 80 characters allows for CR LF characters.

Richard.

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

Dusan Kolar wrote:

Dear all,

reading that

...

according the several style guides, lines shouldn't be too long (longer than 78 characters).

http://www.cs.caltech.edu/courses/cs11/material/haskell/misc/haskell_style_g...

http://www.haskell.org/haskellwiki/Programming_guidelines

I would like to know, whether 78 characters bound still makes a sense... Even if I connect to my linux box with text terminal, it is not a 80x24 characters HW text terminal, but a window emulating this in whatever else OS, thus, I can usually extend this to see longer lines easily.

Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other?

There is a deeper reason. Much work in typography has shown that humans read text best when it's around 76 characters wide; if things get narrower than that then cohesion is lost, if things get wider then it takes a long time to acquire the beginning of the next line. This is the reason why newspapers and magazines are designed with columns at the width they are, why the unix fmt tool has the default settings it does, why mail readers (e.g. Thunderbird) autowrap around there, etc... The historical 80x24 terminal is often cited as the reason for the ~80 character limit, and is as often disparaged as it is praised in light of modern displays (does huge display => many windows, or huge display => one huge window?). But regardless of technical capabilities, there is a cognitive issue at stake. Naturally, code /= text, but there are many similarities; I'm not aware of any HCI studies contrasting them in terms of cognitive load at different widths however. -- Live well, ~wren

The question of which column width is "right" is not a revealing one -- there is little technical or scientific basis to prefer 117 to 80. The line length that we prefer is similarly unenlightening. The number of people who, when pushing for column widths greater than 80, choose 132 instead shows us how just how unexploratory and hidebound folks are on this issue. Like you didn't pick 132 because it's the other traditional terminal size. Column width is rather like driving on a certain side of the road. Is one side better than the other? No. Let's change it! Why? The year after you change the ordinance, people will still be crashing into one another when they get up in the morning and switch by mistake -- and people out in the country will drive on the old side for a decade afterward, to Hell with the law. All this and *not for any benefit*. The effect of liberalizing the line length will be anarchy. I'll be resizing my terminal several times a week because some goofball likes 91 characters while another likes 354. Whereas now, we expect code from most sources to fit in 80 columns *and it does*. I've not changed the width of my terminal for code, email or reading in, well, uhm -- well ever since I changed it to 80. 80 columns is a wise limit because it's in wide use. It's not about whether I like it best -- it's about whether I expect most everyone else to be happy with code that I write in it (and I do). In matters where there is no clearcut best answer, social convention creates a clear expectation. Now in the presence of new knowledge, social convention must be changed. Unfortunately, there is no new science on line lengths. There is no reason to prefer any other column width to 80; the number was chosen a long time ago. Let's accept it and move on. -- Jason Dusek

Jason Dusek wrote:

Really, the whole thing makes me wish we had blasphemy laws.

If any person, in speaking or in writing, shall indicate a preference for column widths other than 80 or indent characters other than spaces (`0x20`) they shall be compelled to present some science or be subject to imprisonment.

I'll definitely add it to the list of questions should I ever conduct a job interview. Just to test how much backing people have for their zeal. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

I've found that some developers have very poor taste in shirts as well, therefore Haskell should have a dress code.... Sorry I'm not buying 80 characters as a way to address bad eyesight. ;-) I think there's supposed to be technology in the editors to deal with that... just as we can try to find good women to dress us better. On Wed, Apr 22, 2009 at 7:38 AM, John A. De Goes wrote:

Another reason for the 80 character limit: some developers have very poor eyesight, which can be overcome with large monitors and large fonts. This won't work if you have to scroll the code.

Regards,

John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration

http://www.n-brain.net | 877-376-2724 x 101

On Apr 22, 2009, at 8:32 AM, Achim Schneider wrote:

Jason Dusek wrote:

...

Really, the whole thing makes me wish we had blasphemy laws.

...

If any person, in speaking or in writing, shall indicate a preference for column widths other than 80 or indent characters other than spaces (`0x20`) they shall be compelled to present some science or be subject to imprisonment.

I'll definitely add it to the list of questions should I ever conduct a

job interview. Just to test how much backing people have for their zeal.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ 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

On 22 Apr 2009, at 8:09 pm, Jason Dusek wrote:

Really, the whole thing makes me wish we had blasphemy laws.

If any person, in speaking or in writing, shall indicate a preference for column widths other than 80 or indent characters other than spaces (`0x20`) they shall be compelled to present some science or be subject to imprisonment.

I did find a paper that claimed that 95-character lines were significantly faster to read than three shorter lengths. On closer study, it turned out that they were using the "paging" model rather than the "scrolling" model: once you came to the end of a (short) page of text, you had to hit the Next button to see the next page. What they had in fact proved was that hitting the Next Page button takes time... Now that I have access to a recent Mac laptop, I've found that in reading plain text, I like to make the lines narrower and to approximate continuous scrolling: read one paragraph, stroke the pad to move the next one up, keep on doing it. There are several important differences between program text and ordinary running natural language text. In particular, program text is two-dimensional in a way that ordinary text is not. By the way, in the era of punched cards, while the *cards* were 80 columns, one's *text area* was not. Typically the last 8 columns were used for a sequence number, so that if you dropped your cards -- yes, this happened -- you could sort them back into order, and to provide editing facilities. So people were really programming with 72-column lines. That seemed to work pretty well, and printers seemed to have no trouble reproducing it in books. I do know a psychologist who has done reading studies; I must see if I can talk him into looking into this.

Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. That fits my observations. In particular, I noticed that your emails were particularly comfortable to read, which might also be partly be caused by the extra indent at the start of your lines, which also seems comfortable. Not sure how applicabable all this is to code, though :-)

Gr. Matthijs

On 23 Apr 2009, at 12:17, Thomas Davie wrote:

On 23 Apr 2009, at 10:02, Matthijs Kooijman wrote:

...

...

Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. That fits my observations. In particular, I noticed that your emails were particularly comfortable to read, which might also be partly be caused by the extra indent at the start of your lines, which also seems comfortable. Not sure how applicabable all this is to code, though :-)

I think the non-applicable to code observation is very likely true – we'd like to be able to write nice descriptive variable names. In doing this, we probably want them to be more than the 1 or 2 characters that Haskellers traditionally use, maybe of the order of 5-10.

Given this, it would seem a shame to only be able to fit 6-13 litterals on a line, that sounds like we'll quickly be having to wrap lines with deffinititions of any significance on them.

My personal preference with Haskell is to ignore the 78 character "limit", but only when layout otherwise becomes horrible otherwise.

Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird.

+1. I sometimes use lines up to 200 characters long, when I feel they would be more readable.

On 24 Apr 2009, at 14:37, Loup Vaillant wrote:

2009/4/23 Miguel Mitrofanov :

...

On 23 Apr 2009, at 12:17, Thomas Davie wrote:

...

Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird.

+1. I sometimes use lines up to 200 characters long, when I feel they would be more readable.

200 sounds awfully long. Do you have any example?

Sure... arrow :: forall (~>) b c d e. ( Arrow (~>), Show (d ~> e), Show (c ~> d), Show (b ~> c), Show b, Show c, Show d, Show e, Arbitrary (d ~> e), Arbitrary (c ~> d), Arbitrary (b ~> c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~> e), EqProp (b ~> d), EqProp ((b,d) ~> c), EqProp ((b,d) ~> (c,d)), EqProp ((b,e) ~> (d,e)), EqProp ((b,d) ~> (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) => b ~> (c,d,e) -> TestBatch

.>

In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example: filterNonRoots (GCase e bs ) = filter ((/= e) <^(&&)^> (not . (`elem` bs))) Bob

On 25 Apr 2009, at 10:51, Daniel Fischer wrote:

Am Samstag 25 April 2009 08:48:16 schrieb Thomas Davie:

...

On 24 Apr 2009, at 14:37, Loup Vaillant wrote:

...

2009/4/23 Miguel Mitrofanov :

...

On 23 Apr 2009, at 12:17, Thomas Davie wrote:

...

Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird.

+1. I sometimes use lines up to 200 characters long, when I feel they would be more readable.

200 sounds awfully long. Do you have any example?

Sure...

arrow :: forall (~>) b c d e. ( Arrow (~>), Show (d ~> e), Show (c ~> d), Show (b ~> c), Show b, Show c, Show d, Show e, Arbitrary (d ~> e), Arbitrary (c ~> d), Arbitrary (b ~> c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~> e), EqProp (b ~> d), EqProp ((b,d) ~> c), EqProp ((b,d) ~> (c,d)), EqProp ((b,e) ~> (d,e)), EqProp ((b,d) ~> (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) => b ~> (c,d,e) -> TestBatch

...

.>

In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example:

filterNonRoots (GCase e bs ) = filter ((/= e) <^(&&)^> (not . (`elem` bs)))

Not that I'd deny that it can sometimes be more readable to have longer lines*, but in this example, would

filterNonRoots (GCase e bs ) = filter ((/= e) <^(&&)^> (not . (`elem` bs)))

be any less readable in your opinion?

Yes – this particular line is mixed in with several other pattern matches, each of which has a similar form, laying it out on one line lets you see the similarities and differences, laying it out on two lines creates visual noise. Bob

Miguel Mitrofanov writes:

On 24 Apr 2009, at 16:37, Loup Vaillant wrote:

...

2009/4/23 Miguel Mitrofanov :

...

On 23 Apr 2009, at 12:17, Thomas Davie wrote:

...

Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird.

+1. I sometimes use lines up to 200 characters long, when I feel they would be more readable.

200 sounds awfully long. Do you have any example?

Something like

newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass)

Nobody would be really interested in "deriving" clause, because it basically says "derive everything possible". Therefore, it seems pointless to move it to another line.

You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) It is just so much clearer than a one liner. I'd like to hear what people think about it, comparing to newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) (Yes, I rewrote it so it actually is in one line. You email editor clearly fooled you.) P.S. I moved your reply down below the citation to make this email easier to understand. -- c/* __o/* <\ * (__ */\ <

Am Samstag 25 April 2009 16:44:45 schrieb Miguel Mitrofanov:

On 25 Apr 2009, at 18:34, Xiao-Yong Jin wrote:

...

Miguel Mitrofanov writes:

...

On 24 Apr 2009, at 16:37, Loup Vaillant wrote:

...

2009/4/23 Miguel Mitrofanov :

...

On 23 Apr 2009, at 12:17, Thomas Davie wrote:

...

Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird.

+1. I sometimes use lines up to 200 characters long, when I feel they would be more readable.

200 sounds awfully long. Do you have any example?

Something like

newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass)

Nobody would be really interested in "deriving" clause, because it basically says "derive everything possible". Therefore, it seems pointless to move it to another line.

You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as

newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever)))

Well, first impression I've got from this was that FirstTransformer, SecondTransformer and the rest are on the same level:

newtype MyCool Monad = MyCoolMonad (FirstTransformer) (SecondTransformer) (ThirdTransformer Whatever)

which is very confusing.

You have a point there. If split over several lines, I'd recommend each line indented further than the previous to indicate nesting: newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) But I wouldn't really prefer that over having it on one line.

...

deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass)

A lot of unnecessary information distracting the reader. It's better kept somewhere else, where it doesn't attract too much attention - like in the end of the line.

There I have to disagree. IMO, having the deriving clause on the same line (unless it's a very short one) obscures the code and makes it *much* harder to read.

On 25 Apr 2009, at 19:08, Felipe Lessa wrote:

On Sat, Apr 25, 2009 at 10:34:05AM -0400, Xiao-Yong Jin wrote:

...

You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as

newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass)

Doubtlessly, this is better than a one-liner, and I don't write lisp :).

Doubtfully, after reading a message from Daniel Fischer.

Also, I don't mistake the transformers as different parameters because of the parenthesis

You should really try Lisp. In my opinion, parenthesis are a kind of noise - too small, too many.

and because they're transformers, reading their names gives you a clue of how they may be used.

So... you really think transformers CAN'T be parameters? You're going to be surprised.

Whoever knows transformers expect to see this kind of nesting.

Whoever knows Haskell - no offense - expects to see both.

On 25 Apr 2009, at 19:59, Felipe Lessa wrote:

On Sat, Apr 25, 2009 at 07:38:59PM +0400, Miguel Mitrofanov wrote:

...

...

Also, I don't mistake the transformers as different parameters because of the parenthesis

You should really try Lisp. In my opinion, parenthesis are a kind of noise - too small, too many.

I don't try lisp because I don't like a lot of parenthesis as well. However the problem isn't with parenthesis, it is with their excessive usage. In this case they're helpful, IMO.

Of course they are. My point was not that everything should be clear without parenthesis, but that the user shouldn't have false impressions - the notation should either give a true impression (like Daniel suggested, with every other line indented more than the previous one - though I don't like it), or not to give any impression at all, so that the reader would be forced to read the noise.

...

...

and because they're transformers, reading their names gives you a clue of how they may be used.

So... you really think transformers CAN'T be parameters? You're going to be surprised. [...] Whoever knows Haskell - no offense - expects to see both.

Haha :), so "giving a clue of how they may be used" means "meaning that they will always be fully applied" now?

Well, then, is that ALWAYS so obvious that this particular name denotes a transformer? Of course, if it's not a standard transformer like StateT or WriterT, but something written by the same guy who invented this MyCoolMonad type?

On 25 Apr 2009, at 21:09, Jason Dusek wrote:

There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length?

Is there a fundamental disagreement here? There are those who are driven by an archaic standard from the width of the terminal screen, and there are those who are driven by the aesthetics of their code. As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree that we should try to keep lines short where possible, but lengthen then when needed. Bob

Am Sonntag 26 April 2009 04:38:42 schrieb Jason Dusek:

...

 As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree...

  Eh? Since when did they mostly agree? The 200 column example   we've seen brought out a lot of disagreement.

Well, to be picky, Bob (Thomas Davie) wrote:

...

As always, opinions on aesthetics differ   slightly, but overall, everyone seems to mostly agree that we should   try to keep lines short where possible, but lengthen then when needed.

And the disagreement is about whether it's needed to lengthen such lines. While I can easily imagine the need for 100-character lines to improve readability, 200 is way beyond my imagination :)

Am Sonntag 26 April 2009 23:08:41 schrieb Jason Dusek:

2009/04/26 Daniel Fischer :

...

While I can easily imagine the need for 100-character lines to improve readability, 200 is way beyond my imagination :)

It's not beyond someone's imagination, though. Would you like that line to land on your screen?

Nope. I like my lines short.

If we do not preserve the old ways, it'll be anarchy all the way down.

-- Jason Dusek

Richard O'Keefe wrote:

On 25 Apr 2009, at 8:59 pm, Miguel Mitrofanov wrote:

...

Something like

newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass)

[...]

For what it's worth, my personal Haskell style lines up

data T = C1 ... | ... | Cn ... deriving (...)

This has the clear advantage that indentation does not depend on the length of the type name as in the quite typical layout of Xiao-Yong Jin: http://www.haskell.org/pipermail/haskell-cafe/2009-April/060541.html

so I'd have this as

newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass)

where the longest line is 86 columns.

(which is still too long as my reply-wrap proofs.) [...] However, indenting by 3 or 6 characters depending on "data" or "newtype" is also a bit arbitrary. Consider: newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving ( Functor, Monad, FirstClass, SecondClass, ThirdClass , SomeOtherClass) Either all alternatives fit on one line or they go on separate lines each. The same should apply to all components of one alternative. Additionally, as above, a long type-application may need to be broken over several lines. (Breaking before "=" and having "=" above "|" looks also nice.) Pretty-printing a comma-separated list (following deriving) is an extra subject with a couple of variations: Putting commas in the front, better indicates the continuation, but the extra space following the open bracket "(" looks a bit odd. (Surely one could also leave a space before the closing bracket, although I wouldn't like spaces around all brackets.) The alternative: (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) has the disadvantage, that the second line is only indented by one character (relative to the previous one), but intending further (+1 or +3 or even one less) is an alternative. (I'm no friend of putting the closing bracket on a separate line in the same column as the opening one. Too easily such indentations are messed up.) Cheers Christian

I think the non-applicable to code observation is very likely true – we'd like to be able to write nice descriptive variable names. In doing this, we probably want them to be more than the 1 or 2 characters that Haskellers traditionally use, maybe of the order of 5-10.

Given this, it would seem a shame to only be able to fit 6-13 litterals on a line, that sounds like we'll quickly be having to wrap lines with deffinititions of any significance on them.

I really like the 80-columns rule. And I also agree that long identifiers can be useful. All this means is that you use up more lines. Note that this can be a good thing: indentation is information, so by using more lines, you give more indentation information.

My personal preference with Haskell is to ignore the 78 character "limit", but only when layout otherwise becomes horrible otherwise.

I consider screen real-estate a very valuable resource (and I'm appaled by the fact that current 21" displays are limited to 1600x1200 when they could go up to 1800x1400 ten years ago), and in this light the 80 columns limit tends to work fairly well: using significantly less (like 50) makes the code really difficult to write, whereas using more tends to waste a lot of space because, while some lines will make good use of the extra columns, most of them won't. Finally, I find that the indentation-pressure imposed by the 80-columns limit forces me to write better code: when code indentation grows too high, I'm forced to move it to a separate function, making the code more readable at the same time (by being forced to choose a name for the function and to choose appropriate arguments and return values). Stefan

* with practically every modern IDE (say, Eclipse for Java), indentation is a non-issue.

How so? In future IDEs, source code might just be a view on an internal representation, but we've have that kind of IDE in the past, and some users developed a definite dislike to tools that wouldn't let them adjust layout to whatever they thought best suited to the task at hand. Unless you mean semantics-based editing, where the IDE should be able to compensate for unwanted side-effects of, say, renaming, or adding/ removing parameters, without resorting to just pretty-printing everything. But as long as programmers need to resort to text editing, IDEs can at best guess their intentions, and some layout styles will be less prone than other to needing adjustments after typical editing tasks.

* indentation should be by fixed amounts (e.g. 4 spaces for each level) and not depend on lengths of identifiers (because you might later change them) (well, actually you won't because we don't have Refactor->Rename that would be aware of namespaces, modules etc.)

I hasn't been maintained for quite a while, and was only Haskell'98, but Renaming was the first refactoring implemented in HaRe, and HaRe was module-aware from about version 0.2: http://haskell.org/pipermail/haskell/2004-January/013508.html HaRe also adjusted indentation if Rename changed identifier lengths. According to its homepage, support for hierarchical modules was added in version 0.3 (the language concept, not the hierarchical libraries code tended to depend on even then, let alone the cabal/hackage of today) Claus