On 16 September 2016 at 13:05, Harendra Kumar <harendra.ku...@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.giarru...@gmail.com>
>> On 16 September 2016 at 12:13, Patrick Pelletier
>> <ppell...@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
Haskell-community mailing list