[Haskell-cafe] Optimal line length for haskell

[Alexander Solla]

On Mon, Oct 29, 2012 at 4:09 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:

>
> On 30/10/2012, at 3:28 AM, Alexander Solla wrote:
> > On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky <michael at orlitzky.com>
> 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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121029/5cbda5dd/attachment.htm>