This thread is inspired by the discussion in https://discourse.haskell.org/t/convenience-in-the-haskell-ecosystem . But that thread is already sprawling, so I thought it would be better to open a second thread which could be more focused on one specific issue: code formatting.
The question that I want to ask is what separates the current state from a possible future where we can say:
and have our code formatted. This is of course inspired by other languages which have this feature, and which is often cited as one of their big benefits. E.g.
go fmt or
The benefit that is cited is precisely the convenience of code formatting, not its availability. The big technical challenge has already been solved, there are code formatters for Haskell. So the remaining challenge of making it convenient is not as much technical as it is social. We have to find a consensus that this is both desirable, and that we can make it happen in a way that satisfies everyone.
For a seasoned Haskell developer, code formatting is not terribly inconvenient. The majority of the users on this board probably know the available formatters, how to install them, and also how to invoke them. But for someone new to Haskell there are currently 3 things which together make it so inconvenient that probably most of them won’t use it on their first projects.
- You have to know which code formatters are available and well-maintained. Also, which of them are popular and which are obscure. Those which are based on
haskell-src-extsshould be avoided, etc.
- You have to know how to install Haskell binaries and make them available on the path. Again, this is trivial for experienced Haskell developers, but if you are just starting out with Haskell you have to look this stuff up.
- You have to know how to invoke them. If we take ormolu and fourmolu as an example, then they have decided on purpose that they won’t try to understand your build system. As a consequence, you have to explicitly invoke them with the Haskell files you want to format. The READMEs suggest using
xmolu --mode inplace $(git ls-files '*.hs')or
xmolu --mode inplace $(find . -name '*.hs'). I am working a lot of beginners who are just starting out with git and the console. Of course I can tell them to type in those commands, but for a lot of them it will just be copy-pasted code. Just try to think back to the time when you were learning about globbing, shell expansion, commandline arguments etc.
The technical challenges are probably pretty minor, at least compared to the work that went into implementing the code formatters themselves. The key challenges are probably social and cultural.
The obvious first one is which code formatter to pick. Brittany is officially unmaintained, and stylish-haskell is much more restricted in scope. (The README says: “The goal is not to format all of the code in a file[…]”.) So the only two really viable alternatives currently are ormolu and fourmolu.(EDIT: I forgot about hindent, which is also still maintained.) The latter is a fork of the former, they share the vast majority of the code and only fundamentally disagree about whether code formatting should be configurable or not. But, very naively, shouldn’t we be able to find a compromise where we say that without a configuration file
cabal/stack fmt behaves like ormolu, and with a configuration file it behaves like formolu? I don’t have any insight into their respective development, but their relationship doesn’t seem to be an acrimonious one.
The other question would be how to make
cabal fmt and
stack fmt happen. Do the maintainers of those tools agree that they should provide such a command. Should it be via a plugin system like the one recently proposed for cabal, should it directly depend on a library or should it invoke an external executable? If it is an external executable, how should it be distributed such that beginners don’t have to know about installation. Via the GHC distribution, ghcup or
stack install invoked in the background?
As the title indicates, it is currently only a dream inspired by the discussion in the other thread. I don’t think it poses any deep technical challenges. Instead it would require someone with the standing in the community and moderating capabilities to make it happen. Someone who would be able to bring the involved actors around a table and create a consensus.