On 16 September 2016 at 12:13, Patrick Pelletier <ppell...@funwithsoftware.org> wrote: > 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.
> But if all packages had to use the new EDSL, then cross-compilation would > essentially become impossible. "All packages migrate to new format" doesn't seem really a plausible option, as I already hinted in the text you quote. There are multiple JVM build tools because they're interoperable (like cabal-install and Stack): each library picks its own build tool, but they can still be linked together. Hpack generates cabal files, stack reuses cabal or hpack files. In principle, option 2 just needs a non-cross-compiled program to produce a package description—say by producing a cabal file. You just need to runghc it, either via ghci or by compiling and running a binary. Option 3 can be trickier depending on details, but the as long as you account for cross-compilation in the design it should be doable. For Template Haskell the problem is deeper (see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/), so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
