[Haskell-cafe] Optimal line length for haskell

Richard O'Keefe ok at cs.otago.ac.nz
Tue Oct 30 08:13:48 CET 2012

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

More information about the Haskell-Cafe mailing list