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> > wrote: >> >> 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 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
