[Haskell-community] [Haskell-cafe] Standard package file format

[Paolo Giarrusso]

On 16 September 2016 at 12:13, Patrick Pelletier
<ppelleti at 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/