Allow per-project customisation of hlint suggestions & hindent styles?

[adinapoli]

Hello there!

I like the idea behind hfmt, and perhaps this ticket doesn't make any sense as the purpose of such formatting tools is to be opinionated (otherwise you destroy its purpose), but nevertheless I guess it's worth asking. At the moment the tool doesn't allow any hlint customisation due to this:

https://github.com/danstiner/hfmt/blob/9c4d1b6c3587d684060cd2fae9f329261b1f8014/src/Language/Haskell/Format/HLint.hs#L25

Nor any tweaking of the hindent style:

https://github.com/danstiner/hfmt/blob/6ff0192b1a42b7b67e74569e66a8a6551b26e967/src/Language/Haskell/Format/HIndent.hs#L19

It might make sense though to have a certain degree of freedom.

Do you think such freedom is beyond the scope of hfmt (cc @filib) ?

Thanks!

Alfredo

[philipcunningham]

@adinapoli I'm curious to hear what @danstiner thinks - I can definitely see two sides to the coin!

[danstiner]

Being opinionated and consistent by default is definitely intended, but allowing customization has been in the back of my mind and is definitely within scope. It just didn't make the initial release out of a desire to get this out the door.

Developers will always have differing opinions on style, sometimes for very good reasons! A universal Haskell style would be neat to have, but it doesn't seem the community is near being in agreement. Just look at the hindent project where there is really no default style. I chose Andrew Gibiansky's style for hfmt as I felt it best matched other Haskell code I had seen, but Chris Done/Johan Tibell have well thought-out alternative styles that arguably would be good choices.

My ideal implementation would be to automatically pick up per-project HLint/hindent/stylish-haskell setting files in such a way that they can be used by both hfmt and the individual tools, thus seamlessly fitting into existing workflows. I already have some logic that specially handles directories containing .cabal files, that or similar could be extended to appropriately pick up custom settings.

That said, unless this is blocking someone from utilizing the tool there are other things like automatically applying hlint refactorings that I will probably work on before this. Any contributions would of course be welcome though.

Thanks for the feedback and interest in the project, keep it coming!

[adinapoli]

Hey @danstiner , thanks for the quick and comprehensive reply!

I think what you say makes a great deal of sense. There are (I suppose) different ways you could achieve such seamless integration. On top of my mind I can think of at least two:

1. Allow hfmt to accept an hindent style + an hlint config file via the command line. In this scenario you would extend the CLI to look something like this:

hfmt -w --hindent-style=johan-tibell --hlint-config=/path/to/Hlint/config

This would at least give people the possibility to invoke hfmt with a certain degree of freedom relatively easily.

1. Have a custom config file for hfmt (e.g. .hfmt) that can be specified either top-level (.e.g. $HOME/.hfmt) or per project and that hfmt will read from before proceeding with the formatting. Ideally it would honour the local, per project file first and then fallback to the global. If neither of the two can be found, a sensible setting is used. As regards the file format itself, I guess popular choices could be json, toml, or even INI.

Does this make sense or is very far away from what you had in mind?

Thanks!

A.

[danstiner]

The second option you describe is what I was thinking of. stylish-haskell uses that pattern for determining its config: https://github.com/jaspervdj/stylish-haskell#configuration. Taking individual CLI parameters for each tool seems annoying to type and inflexible to put into a git hook etc in that it would be difficult to change the command line used if the set of supported tools ever changes.

Format-wise yaml or json would likely be my preference based on their popularity, but anything should be fine. (Hadn't seen toml before, looks like a much nicer cousin of INI) This should be a simple file just specifying where to find the HLint / stylish-haskell config files or in the case of hindent which seems to not have an standard configuration file specifying the style name as you showed. Optionally taking in the hfmt config file path as a CLI parameter seems reasonable as well.

[adinapoli]

Gotcha. I think that might make sense then to stick with the "status quo" stylish haskell is enforcing and use yaml and the same way or looking up for a config. It might give the user a sense of "continuity". That's my 2 cents ofc!

And I will be very much +1 in having the possibility to pass a config file with -c !

[philipcunningham]

Thinking about this more, I don't think hfmt should allow multiple style definitions. It should be opinionated, much in the way gofmt is.