The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it.

So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file.

Alan

On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar <harendra.kumar@gmail.com> wrote:
On 16 September 2016 at 12:35, Imants Cekusins <imantc@gmail.com> wrote:
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.

-harendra

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.