On 16 September 2016 at 12:13, Patrick Pelletier 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-g...), so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

On 16 September 2016 at 13:05, Harendra Kumar wrote:

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.

I agree "full-fledged build system" is not a possible immediate goal. But an EDSL for expressing cabal projects (as they are today) would still be in scope of your proposal—and I thought you liked the idea (see quote below). Using the earlier options: option 3 is not in scope of this thread, but option 2 is, with the only danger that the design space is so big to present a challenge. Quoting from Harendra Kumar's earlier mail:

...

Why not adopt (a subset of) .hs AST file format to structure both project and package files?

Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language.

For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases.

On 16 September 2016 at 16:08, Paolo Giarrusso wrote:

...

On 16 September 2016 at 12:13, Patrick Pelletier wrote:

...

On 9/16/16 2:36 AM, Paolo Giarrusso wrote:

...

...

...

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.

-- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/