On Mon, Oct 29, 2012 at 4:09 PM, Richard O'Keefe
<ok@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@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.