This seems to have gone into a different direction. The original point was about the package specification format and not expressing a full fledged build system. That is an entirely different ballgame. The main point of the thread was whether it makes sense to use a single specification format for both stack and cabal install (YAML vs .cabal and then TOML came into picture). Haskell does not seem to be a choice for a package specification format unless we have a very different goal in mind.
-harendra On 16 September 2016 at 16:08, Paolo Giarrusso <p.giarru...@gmail.com> wrote: > 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 >
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
