
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
On 16 September 2016 at 12:35, Imants Cekusins
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.