Portability

[augustss]

Cabal claims to be "A framework for packaging Haskell software". But after some minor inspection, it looks like it's a tool for ghc, requiring ghc.
If Cabal wants to be for Haskell, shouldn't it be written in Haskell2010? It looks very difficult to use Cabal without a long list of GHC features.

Not even the package that just deals with the syntax looks simple. (It seems I will have to write my own.) It's a pity that Cabal gave up Hugs support.

[gbaz]

Requiring ghc to compile it does not prevent cabal from being a framework for packaging haskell software in general. The framework consists of a file specification (cabal files), a packaging format (a cabal package as a tgz) as well as tools (Setup.hs files, cabal-install) for building such packages and repositories for storing such packages. The fact that the tools -- Setup.hs and cabal-install require ghc to build does not prevent cabal from being used to package and build arbitrary haskell software. I'm writing the above not to be pedantic, but to (hopefully) point out a potential way forward, even if partial.

Let us call an example compiler hc. We wish to use hc with cabal. How do we do so? The dumbest way to do so is to write a wrapper for hc such that it accepts the same flags ghc does and pretends to be ghc when queried. Then we can call cabal-install or Setup.hs passing --with-compiler=hc-wrapper.

That's pretty ugly though!

Instead, we can extend the known compiler flavors with hc directly, and teach Distribution.Simple.Build and friends to pass the flags and arguments in a way that it expects.

There's examples of doing this with ghcjs and HaskellSuite among others, and some relevant code is e.g. here

cabal/Cabal/src/Distribution/Simple/Build.hs

Line 846 in 3c06125

buildLib flags numJobs pkg_descr lbi lib clbi =

With such extensions, we can use Setup.hs and cabal-install to build, install etc packages with hc. This would be equally true if such tools were not written in (ghc-or-otherwise-flavored) Haskell at all, but Rust, or whatever else.

There remains the problem that hc cannot itself compile such tools, and that's unfortunate, I agree. I suspect that some of the extensions that Cabal-syntax claims it uses are perhaps unnecessary -- the cabal file was just forked out of the general Cabal file when we split it out.

I don't think its feasible to remove all extensions beyond H2010, but I would hope a fair number can be, and I think the cabal team would be open to that.

I suspect things may just be too far for the Cabal library to receive similar treatment.

[ffaf1]

https://cabal.readthedocs.io/en/stable/buildinfo-fields-reference.html#

[augustss]

Thanks. Not exactly a grammar, but better than nothing. :)

[gbaz]

Your argument is fair. I was just trying to lay out how much we could accomplish even without being able to build cabal itself with a different haskell compiler. A monoculture of haskell compilers has certainly degraded our portability vision -- when people add code making use of nonstandard features it has been (outside of a backwards compat window) very hard to find reasons to say "no" (and arguably, had we done so, it would have deterred contributions we desired).

On grammars specifically, the code in cabal-syntax is a rather monstrous looking (but flexible in practice) tagless encoding: https://hackage.haskell.org/package/Cabal-syntax-3.10.2.0/docs/Distribution-PackageDescription-FieldGrammar.html

Since it can take multiple backends, one project I've long wanted has been to write a backend that outputs BNF directly. Something like that would allow us to precisely document the cabal file format and make writing standalone parsers far easier.

[dcoutts]

Thanks. Not exactly a grammar, but better than nothing. :)

The original Cabal spec never had a "proper" grammar. It was sadly defined by code. Several people (myself included) did a lot of work over the years to get it into a half-way sane state, while mostly maintaining backwards compat.

[augustss]

Maybe I'll convert my parser to a BNF grammar. Or I could ask chatgpt to do it.

[ffaf1]

Data point, actual number of extensions in Cabal-syntax:

$ grep -ri --no-filename "\# Language" | sort  | uniq -c  | sort -rn
     73 {-# LANGUAGE DeriveGeneric #-}
     73 {-# LANGUAGE DeriveDataTypeable #-}
     21 {-# LANGUAGE OverloadedStrings #-}
     21 {-# LANGUAGE CPP #-}
     16 {-# LANGUAGE ScopedTypeVariables #-}
     16 {-# LANGUAGE FlexibleContexts #-}
     13 {-# LANGUAGE RankNTypes #-}
     11 {-# LANGUAGE GeneralizedNewtypeDeriving #-}
      8 {-# LANGUAGE FlexibleInstances #-}
      8 {-# LANGUAGE DeriveFunctor #-}
      8 {-# LANGUAGE BangPatterns #-}
      7 {-# LANGUAGE MultiParamTypeClasses #-}
      5 {-# LANGUAGE DeriveTraversable #-}
      5 {-# LANGUAGE DeriveFoldable #-}
      4 {-# LANGUAGE TypeOperators #-}
      3 {-# LANGUAGE UndecidableInstances #-}
      3 {-# LANGUAGE TypeFamilies #-}
      3 {-# LANGUAGE PatternSynonyms #-}
      3 {-# LANGUAGE PatternGuards #-}
      3 {-# LANGUAGE GADTs #-}
      3 {-# LANGUAGE FunctionalDependencies #-}
      3 {-# LANGUAGE ConstraintKinds #-}
      2 {-# LANGUAGE StandaloneDeriving #-}
      2 {-# LANGUAGE Rank2Types #-}
      2 {-# LANGUAGE DefaultSignatures #-}
      1 {-# LANGUAGE UndecidableSuperClasses #-}
      1 {-# LANGUAGE Trustworthy #-}
      1 {-# LANGUAGE RecordWildCards #-}
      1 {-# LANGUAGE PolyKinds #-}
      1 {-# LANGUAGE LambdaCase #-}
      1 {-# LANGUAGE DeriveGeneric      #-}

[dcoutts]

@augustss we really tried for many years to remain agnostic, but it's very difficult to do in practice when there are no other actually supported Haskell implementations (i.e. releases that work on current platforms).

Cabal for years had supposed support for hugs, nhc, jhc, etc etc. But in practice none of these compilers existed, and so support could not be tested. And we need to rely on the (non-existent) people supporting those compilers to also co-maintain the Cabal support for their compiler. Eventually this becomes impossible to justify.

The overall architecture of Cabal is still designed to allow for multiple Haskell compilers, though bit-rot has probably eaten away at that somewhat.

The way I would suggest you approach this initially is this:

• assume (initially) that Cabal gets built with ghc
• update Cabal to support your new hc
• gradually update both your hc and Cabal to the point where Cabal can be built with your hc

[augustss]

Just because you no longer support other compilers than GHC doesn't mean you have to go wild with GHC-only language extensions. It would be nice if Cabal could be compiled with a Haskell2010 compiler. As it is, it's a tall order to compile Cabal with anything but GHC.

I looked at the Cabal code base and decided that it's easier to rewrite as much of Cabal as I need than to compile Cabal with my compiler. I don't need the full glory of Cabal; just enough to build packages.

[dcoutts]

You'd need some practical argument to make to (potential) contributors to say why they must stick within some constraints. When there are no other compilers, that's a hard argument to make. And Cabal's biggest maintenance problem is that is scares off contributors. Making them write Haskell2010 wouldn't help with that.

Basically, we did try that for several years, but in the absence of any other compilers that ship sailed.

[augustss]

As I said before, I think Cabal is fine as it is. But I also think the description should be honest. It's a tool for ghc by ghc; it's not a Haskell tool (unless one equates Haskell with ghc).

[augustss]

Since I have now written my own Cabal (MicroCabal) I will close this discussion, unless someone has something to add.
Making Cabal portable is a lost cause.