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.ku...@gmail.com>
wrote:

> On 16 September 2016 at 12:35, Imants Cekusins <ima...@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.
>
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Reply via email to