On 9/16/16 2:36 AM, Paolo Giarrusso wrote:
(Resending from right address)
We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure.
Options 2 and 3 both require running Haskell code at build time. This presents problems in a couple of cases: Cross compilation: There are already a couple of cases where we need to run Haskell code at build time: Template Haskell, and custom Setup.hs. Neither of these are supported in cross-compilation. (The former is a ghc issue, while the latter is a Cabal issue.) So I'm assuming that the new Haskell-based EDSL wouldn't work in cross-compilation, either. The difference is that Template Haskell and custom Setup.hs are only used by some packages. But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. Platforms without ghci: Even when not cross-compiling, some platforms don't support ghci. (This is usually the less popular platforms. Not too long ago, it even included ARM.) ghci support is necessary for Template Haskell, and I assume the EDSL would work the same way. So then less popular platforms would be left out in the cold. --Patrick