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
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.
Haskell-community mailing list