Indentation issues

[geraldus]

We have a lot of issues related to indentation and a lot of efforts to fix this. However, having done so much job we still struggling with this. Maybe we are doing something wrong and should re-think this question a bit deeper?

I think this is because Haskell itself quite complex and flexible in question of indentation. It allows programmers many valid ways to indent the code, and trying to predict what is the best indentation choice for every single haskeller seems to be very complicated task.

Here are some examples.

Data type decalrations

-- some people prefer this style
data ABC = A
    | B
    | C
-- other may prefer this one
data ABC 
    = A
    | B
    | C
-- another example
data ABC = A
         | B
         | C

do keyword

action = do
    foo
    bar

action =
    do bar
       baz

Function arguments

foobar baz
    quux
    norf

foobar
  baz quux norf

foobar
  baz
  quux
  norf

foobar baz quux
       norf

There is no reliable way to predict correct indentation position user expects for all cases. Sticking indentation to single style and omitting other looks like compliment some people and discriminate others. Indentation should not be based on style, but on code validity from Haskell perspective.

So, maybe we should dramatically simplify indentation? Here some of my thoughts:

• if several previous lines are identically aligned at some column pick this columns as default indentation for new line

main = do
  foo
  bar
  _
main =
  do foo
     bar
     _

data A = A { a :: ()
           , b :: ()
           _
data A = A { a :: (),
             b :: (),
             _
data A = A
  { a :: (),
  , b :: ()
  _

• indent newlines one step further based on tab width in cases of inner blocks

main = do
    _
main =
    _
data A =
    _
data A = A { a :: ()
    _
functionA = functionB (
    _
data A = A
_

• avoid any "smart" tries to predict preferred indentation position when cycling, rather combine positions based on tab width with columns where words starts on previous line

-- _ is tab width based step (in this example 4)
-- . is word beginning step
function = foobar baz quux
_   _   _. ._   _ . _ . _

Not sure what default should be picked in these cases

main = someFunc
?   ?
main = somFunc foo
?   ?          ?

What else is needed?

We can also support possibility to write "smart" indentation backends for different styles for those who really interested in, it is possible to provide a special haskell-indentation-hook which supposes to be a list of functions taking current buffer and maybe a line number and return a list of indentation positions. Then we can define default indentation step provider and allow to override it.

[gracjan]

In languages where braces or parentheses delimit block indentation, that is the TAB does has only aesthetic meaning: it just indents the line so that it looks better. To the contrary in Haskell (but also Python) TAB has semantic meaning: it is equivalent to either { or }.

I think our issues come from this fundamental misunderstanding that TAB is a key that can change source code meaning.

So far we have followed Emacs convention that TAB makes the source code prettier and nothing else. Whole concept of electric-indent-mode hangs on this assumption: one can just blindly indent a line and move on! This is not the case in Haskell. When in other languages TAB has only aesthetic meaning in Haskell it has both aesthetic and semantic meaning.

[gracjan]

There are indentation scenarios when everybody seems to agree on. These include how to indent after where, do, let and of, how to continue when in parenthesized expression {}, () or [], how to continue with , and ; at the end of line or at the beginning of line. That seems to be solid consensus.

A bit of a question is how to indent the where keyword itself.

The big question is how to continue current expression. I've noticed the following requests:

1. Indent continuation by basic-indent independent of what is happening.
2. Indent so that function arguments align.
3. Indent specially for :: and -> so that those align, everything else according to item 1.
4. Indent specially data, = and | so that those align, everything else according to item 1.
5. Indent specially for = and | as guard introduction, everything else according to item 1.

So there does not seem to be that many contentious points in the indentation scenario.

We can either aim at providing maximum flexibility and offer all potentially interesting indentation points or aim at maximum determinism and be able to use Emacs concept of indentation-as-aesthetic-only tool.

[geraldus]

Yes, where keyword is tricky, often I see people have 4 spaces as indent unit but indent where using only two. Personally, I use two spaces everywhere and indent where this way:

main =
  do foo
     bar
  where
    foo = blah
    bar = blah blah

[geraldus]

I think that we unnecessarily overcomplicated indentation logic. Can we follow this principle:

• collect all possible indentation steps based on tab width and delimiting whitespace from preceding line;
• pick previous line margin first as default indentation step;
• indent one step further only iff layout requires it, e.g. indenting new line as previous one will produce invalid Haskell code;
• provide a way to override default behaviour: e.g. haskell-mode-collect-indentation-function (to override default way completely) and haskell-mode-transform-indentation-steps-function (to manipulate on indent step list)

?

[PierreR]

If I understand this a bit, it would ease the typing of record declarations

data A = A
  { a :: (),
  , b :: ()

So 👍
Thanks for your effort to take a stab on indentation issues.

[gracjan]

@geraldus, there used to be indentation mode called haskell-simple-indent. It differed from you are saying in two important ways:

1. It did not align on tabstops.
2. It analyzed multiple preceding lines so that indentation stops could trickle down unless they were covered by later lines.

In practice it did not work that well because of the whitespace significance. It was removed it pull request #958.

Right now as I think about this it could be fixed by using lexeme boundaries as indentation stops then it would most probably work better. Experiment is needed so we need somebody that will sit down and actually write the code. I suggest to go with this mechanism:

1. Tokenize preceding lines, record the column where each lexeme is starting.
2. Add tab to tab stops.
3. Sort. Use for indentation TAB and S-TAB.

The code in haskell-simple-indent seems like a good start.

Personally I think there is still some low hanging fruit to fix in haskell-indentation and plan to work there for a little while.

[geraldus]

I would be glad to write some code, but currently there are several task I already have assigned myself. So, if you'll manage to fix haskell-indentation it will be really cool. And I'm still affected by #896 😌

[gracjan]

Note that #896 is actually one level above. I mean whatever indentation candidate list is generated you have a couple interaction problems, for example:

1. What to do on RET?
2. What to do on RET RET?

And that is a different matter that we need to also solve. But then it requires different skills as it is about user interaction.

[gracjan]

@PierreR: You seem to be affected by #1125. Now a puzzle: how to reconcile the wish to align = with | and the wish to use 2 spaces only indentation? What is the expected indentation for:

data User = User
  { userName :: String }
          | Admin
  { adminName :: String }

?

[geraldus]

Wow, what a tricky case! Is it valid code? Normally, I would write:

data User
  = User
    { ...
    , ... }
  | Admin
    { ...
    , ... }
-- or
data User
  = User
      { ...
      , ... }
  | Admin
      { ...
      , ... }