Difficulty estimation for creating “explicit delimiter” and “implicit delimiter” modes

[chrisdone]

I’m wondering, how hard would it be to add a pass in ormolu to do two modes:

1. Insert explicit parents, braces, semi colons, etc. in various places.

2. Remove all unnecessary parens, braces, semi colons, etc.

My idea is that for projects already using ormolu, it would be a neat editing mode in various editors to reformat the source of e.g. the current declaration in mode (1), which is very easy to manipulate with editor modes like paredit and it also has a visual aid, and once done editing, it flips it back via (2).

Notably, an editor which edits trees of delimiters, like paredit, can edit a subset of the real AST and can achieve a lot of value on this basis. Most obviously, automatic indentation when you hit new line is easy because it’s all explicit.

So e.g.

foo = do
 x <- foo bar
 case x of
   K a -> wobble
  where k = t

becomes

foo = (do {
 (x) <- (foo bar);
 (case (x) of
   (K a) -> (wobble));
  })
  where { (k) = (t) ; };

This would be an alternative attack on the problem dealt with by structured-haskell-mode.

Thoughts welcome.

[mrkkrp]

Well, first of all this would effectively introduce a configuration option, which doesn't go well with Ormolu's philosophy. If we imagine that it would be implemented in fourmolu or some other independent fork, then I'd say I'd have go all over the code and do countless manual adjustments (hard and error-prone).

[chrisdone]

Now that I think about it, perhaps instead I could make a tool that parses with ormolu/ghc-lib-parser, does some AST transformations via syb/generics, and then prints with ormolu. Assuming ormolu never adds or removes optional delimiters or groupings.

[chrisdone]

Thanks!