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

[Paolo Giarrusso]

On 16 September 2016 at 13:05, Harendra Kumar <harendra.kumar at gmail.com> 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 <p.giarrusso at gmail.com>
> wrote:
>>
>> On 16 September 2016 at 12:13, Patrick Pelletier
>> <ppelleti at funwithsoftware.org> 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/