cabal icon indicating copy to clipboard operation
cabal copied to clipboard

Reconsider warning about missing languages

Open ffaf1 opened this issue 8 months ago • 2 comments

It's a curious problem. The GHC* "languages" will multiply in the future (iiuc GHC SC's current intentions). So, simply two branches (if/else) won't be enough soon. I'm wondering if we should support something like default-language: GHC which would mean the latest supported GHC*.

Semantically, saying "give me the latest GHC language that this compiler supports" comes dangerously close to not specifying a language — the very situation cabal check was supposed to flag. But I think this idea behind the check hasn't aged well (due to invention of GHC* "languages") and we should revisit it.

Originally posted by @ulysses4ever in #11017.

Consider also what @tonyday567 is doing in #11017, abstracting away/backporting language extensions so they are usable to older GHCs. It is a valid usecase.

ffaf1 avatar Jun 26 '25 01:06 ffaf1

Well, after seeing the actual code I'm not optimistic about my initial idea to allow requesting the latest GHC*. Initially I thought it could spare us from the ugly conditionals, but it looks like you still need the conditional — for specifying the default-extensions missing from particular GHC-languages.

At the time of writing I forgot about elif, which solves my initial worry about more than two GHC*-languages.

In summary, I don't really see a way to improve things significantly. But maybe others do?..

ulysses4ever avatar Jun 26 '25 01:06 ulysses4ever

I had seen that cabal-version: 3.4 was making default-language optional, saw that GHC2024 was in the books, and just assumed we would default to that now. +1 for cabal check.

My original attempt at backporting GHC2024 was wrong and a new attempt is reproduced below. I had forgotten to add the GHC2021 => GHC2024 additions to the pre-9.2 set. Without stanzas it might have been messy, but I'm really happy with composability here - I can just cut and paste the pragmas from the docs, name the stanzas and then forget about extension lists for a few years. +1 for stanzas.

It's not ugly. I'd have liked to put the extension lists at the bottom, and the import dec at the end so I could highlight the default-language aspect of the logic, but that's a small nit pick. The hardest part in getting this right was working out what impl was and that elif exists. The cabal language needs a haddock index page!

common ghc2021-additions
  default-extensions:
    BangPatterns
    BinaryLiterals
    ConstrainedClassMethods
    ConstraintKinds
    DeriveDataTypeable
    DeriveFoldable
    DeriveFunctor
    DeriveGeneric
    DeriveLift
    DeriveTraversable
    DoAndIfThenElse
    EmptyCase
    EmptyDataDecls
    EmptyDataDeriving
    ExistentialQuantification
    ExplicitForAll
    FlexibleContexts
    FlexibleInstances
    ForeignFunctionInterface
    GADTSyntax
    GeneralisedNewtypeDeriving
    HexFloatLiterals
    ImplicitPrelude
    InstanceSigs
    KindSignatures
    MonomorphismRestriction
    MultiParamTypeClasses
    NamedFieldPuns
    NamedWildCards
    NumericUnderscores
    PatternGuards
    PolyKinds
    PostfixOperators
    RankNTypes
    RelaxedPolyRec
    ScopedTypeVariables
    StandaloneDeriving
    StarIsType
    TraditionalRecordSyntax
    TupleSections
    TypeApplications
    TypeOperators
    TypeSynonymInstances

  if impl(ghc <9.2) && impl(ghc >=8.10)
    default-extensions:
      ImportQualifiedPost
      StandaloneKindSignatures

common ghc2024-additions
  default-extensions:
    DataKinds
    DerivingStrategies
    DisambiguateRecordFields
    ExplicitNamespaces
    GADTs
    LambdaCase
    MonoLocalBinds
    RoleAnnotations

common ghc2024-stanza
  if impl(ghc >=9.10)
    default-language:
      GHC2024
  elif impl(ghc >=9.2)
    import: ghc2024-additions
    default-language:
      GHC2021
  else
    import: ghc2021-additions
    import: ghc2024-additions
    default-language:
      Haskell2010

tonyday567 avatar Jun 26 '25 21:06 tonyday567