Ergonomics versus Cabal-faithfulness in defaults

[quasicomputational]

Some of Cabal's defaults for fields are not great for ergonomics and boilerplate reduction. In #112 I suggested setting our default default-language to Haskell2010, which is what about 99.5% of code is going to want. @ocharles reasonably pointed out two things: this is a divergence from what Cabal does, and Dhall is powerful enough that users can define their own defaults.

Regarding the first point, hpack fills in these sorts of things by default and people don't seem to mind it, but dhall-to-cabal does hew rather more closely to Cabal.

Regarding the second point, that's also correct, but I'd like to see dhall-to-cabal have great out-of-the-box usability without having to get into abstraction and possibly forking upstream code for simple things like default-language, where there is a sensible choice of default.

We've got the capability now to define multiple sets of defaults in Haskell code and to manipulate them as first-class objects. Maybe this offers a solution: two sets of defaults, a 'give me what Cabal does' set and then an opinionated set targetting boilerplate reduction and ergonomics (or possibly several opinionated sets with different objectives). cabal-to-dhall can learn to switch between them (and then let the meta-default debate begin), and users can easily get at one or the other by changing prelude.defaults to prelude.defaults-extra in their code.

[jneira]

Thinking about the possible caveats, i only can be a little bit worried about something you commented in #112: "We can figure out a plan to deal with Haskell2020 or whatever when it comes."
When the new language arrives the change (when, why, etc) from old to new one could be problematic. Otho users will have to pay that freedom with (a little bit?) of boilerplate.

[quasicomputational]

It's a fair point that we can't predict the future; every opinionated default is a risk. I think it's a small risk that Haskell2020 will break compatibility with Haskell2010 in any kind of significant way. I think we're already taking a bigger compatibility risk with the default cabal-version.

In the worst case, we could create another set of defaults, prelude.defaults2020 or something: leave old code working but without the newer bells and whistles, and then update the new default set until we run into another difficult case.