cabal icon indicating copy to clipboard operation
cabal copied to clipboard

Document that default-language defaults to Haskell98

Open alt-romes opened this issue 1 year ago • 15 comments

I believe in the last Cabal dev meeting we agreed that it would be better for Cabal to default to Haskell98 when no default-language is specified in the package. This is already the current behaviour, however, I believe it is undocumented.

This ticket tracks documenting that not specifying a default-language makes Cabal default to Haskell98

alt-romes avatar Jan 29 '24 10:01 alt-romes

I was going to update the docs (and manage the relevant tickets), when I noticed occourrences of defaultLanguge = which are not Haskell 98. First one in repl

https://github.com/haskell/cabal/blob/46a7bfc922d62477cc9de061a6dc0d3c91cdd9ee/cabal-install/src/Distribution/Client/CmdRepl.hs#L304-L309

Second one in withContextAndSelectors, which is used in a number of places (build, run, repl itself).

https://github.com/haskell/cabal/blob/46a7bfc922d62477cc9de061a6dc0d3c91cdd9ee/cabal-install/src/Distribution/Client/ScriptUtils.hs#L374-L377

ffaf1 avatar Jan 31 '24 12:01 ffaf1

@ffaf1 Oh dear...

What do you think is the main default, the one by which more things are determined? The actual option passed to GHC defaults to Haskell98, but if the option is set to Haskell2010 before then that would be the "main" default.

Could you investigate to determine if actually we use Haskell2010 by default in most places?

An easy way could be to write a simple package without default-language, and print the ghc invocations with -v2 and grep for the Haskell version passed to them.

alt-romes avatar Jan 31 '24 12:01 alt-romes

-v2 only mentions Haskell98, as you correctly guessed.

I have created a draft (#9675) to see if nothing breaks changing 2010→98. If everything is green, steps will be:

  • bless Haskell98 as a default
  • add a non-"Hackage will refuse this package" cabal check warning
  • update documentation to reflect the default

ffaf1 avatar Jan 31 '24 13:01 ffaf1

Why default to Haskell98, which, I believe, is superceded by Haskell2010? 2010 is the current standard. Is there any context one can think of where 98 is preferable to 2010?

ulysses4ever avatar Jan 31 '24 13:01 ulysses4ever

Nope there isn't. My idea was just to: a) get $BLESSED in one place and b) document current behaviour.

ffaf1 avatar Jan 31 '24 13:01 ffaf1

Yeah, having ^a^ consistent global default would be a big step forward regardless of the actual value.

ulysses4ever avatar Jan 31 '24 14:01 ulysses4ever

Why default to Haskell98, which, I believe, is superceded by Haskell2010? 2010 is the current standard. Is there any context one can think of where 98 is preferable to 2010?

I'm not sure to what extent users are writing cabal packages without default-language fields, however, if they are, changing the default from Haskell98 to Haskell2010 may break things.

In having no reason to change the default (which seems to be rarely used), I don't think we should. Haskell98 is already the implicit default, so we simply document it as such.

alt-romes avatar Jan 31 '24 16:01 alt-romes

CI passed meanwhile, which most likely means that most likely those Haskell2010 were overwritten along the way.

ffaf1 avatar Jan 31 '24 16:01 ffaf1

This ticket tracks documenting that not specifying a default-language makes Cabal default to Haskell98

In having no reason to change the default (which seems to be rarely used), I don't think we should. Haskell98 is already the implicit default, so we simply document it as such.

Absent default-language was meant to use compiler's default whatever it is: neither passing -XHaskell98 nor -XHaskell2010 nor -XGHC2021. Quoting https://github.com/haskell/cabal/pull/6926:

Note: the default language is whatever is the compiler's default. The GHC-8.10 default is its variant of Haskell2010 with NondecreasingIndentation and without DatatypeContexts

Defaulting to Haskell98 / Haskell2010 could break packages in the wild. One could fortify a future version of Cabal format (e. g., say that if Cabal file specifies cabal-version: 3.12 then no default-language means Haskell98 or whatever), but should not silently change semantics of existing cabal-versions.

Bodigrim avatar Feb 15 '24 23:02 Bodigrim

It won't break them because we're documenting what it was actually doing (which was not what it was intended to do). If that had caused breakage then we would have heard about it by now.

geekosaur avatar Feb 15 '24 23:02 geekosaur

I see, thanks.

For the reference, the existing documentation says:

default-language is optional. The Default value is to use the compiler’s default language.

Bodigrim avatar Feb 15 '24 23:02 Bodigrim

Yes, that's why this PR to correct that. Changing to the incorrectly documented behavior would require a Cabal-version bump to avoid breaking existing packages.

geekosaur avatar Feb 15 '24 23:02 geekosaur

Thanks to @alt-romes, we are now sure that there are at least two defaults:

  • Haskell2010 for scripts (but not genrally cabal run, mind you).
  • Haskell98 for cabal repl and cabal build and non-script cabal run.

The situation is more complicated than we expected.

ffaf1 avatar Mar 04 '24 17:03 ffaf1

There is of course a duty to document current behaviour, but everything is so fragile (targets are slices combined with mplus, meaning that the first non-Nothing target has priority) that finding another more principled way of affirming what the default is in the codebase could be the right path, too.

If we don't, we rely on developer remembering not to shuffle slices. A Monoid is non commutative, but that is easily overlooked during a refactor.

ffaf1 avatar Mar 04 '24 17:03 ffaf1

I suppose you are right that this may be to fragile to go on @ffaf1. But Cabal breaking builds or scripts will be very bad.

If we are to bump defaults, we should probably make the default 2010 (rather than 98 or whatever GHC language edition) as it will:

  1. likely subsume, without breaking, users relying on Haskell98 implicitly
  2. and not break users with scripts without a default language for which the default is already Haskell2010 -- these may even be more common than build-oriented packages in the wild without a default-language.

alt-romes avatar Mar 04 '24 17:03 alt-romes