[Haskell-cafe] Coding conventions for Haskell?

Evan Laforge qdunkan at gmail.com
Mon Sep 27 17:57:15 EDT 2010

On Mon, Sep 27, 2010 at 2:09 PM, aditya siram <aditya.siram at gmail.com> wrote:
> How do you guys indent long function arguments? I run into this all
> the time with the 'maybe' function which takes 3 arguments:
> maybe :: b -> (a -> b) -> Maybe a -> b
> I usually end up doing things like (pretend the arguments are aligned
> if you're not using a monospace font to view this):
> maybe do-if-Nothing
>          (\x -> do-if-Just x)
>          maybe-value
> This gets a little unwieldly if the any of the arguments stretch over
> one line like:
> maybe do-if-Nothing
>          (\x -> ...
>                  ...
>                  something
>          )
>          maybe-value

I do basically like that only I don't try to line up vertically.  One
indent to continue a line, nested indent for a nested continued line.
However, I tend to factor out the long values with let or where.  I
find it hard to read when everything is coming from some third
argument which is a tiny nub at the end of a giant expression.  And if
you factor out the "if just" case, you can also more easily make the
transition to monadic style if you find yourself with too many
'maybe's in sequence.  If you can eta-reduce that last arg, though, it
can be pretty:

defaulted = maybe deflt $ \v -> [ do ]

One place I do have difficulty is in pattern matching, because you
can't factor that out as easily.  I do use view patterns sometimes for
that, but only when it's a common pattern.  So I wind up with a nested

function too many arguments
        with (Complicated (Pattern matching)) =

case x of
    Pattern (Match
            Is Way Too Long) ->

It's ugly but rare.  'let' within a 'do' is a particular culprit
because right off the bat you've got one indent for 'do' and then the
'let' forces two more indents.  Sometimes the too many arguments can
be factored into a single type, sometimes nasty nested pattern matches
can be factored into view patterns or a data structure that reflects
its access pattern rather than building pattern or whatever.

More information about the Haskell-Cafe mailing list