Am 16.09.2016 um 09:22 schrieb Alan & Kim Zimmerman:
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.
A little-hyped aspect of Gradle is that it has two strictly divided phases: Phase 1 builds the dependency model, phase 2 executes it. Once phase 1 finishes, the dependency model becomes read-only, phase 2 is not allowed to modify it. On the plus side, this makes it easy for tools to reason about the model: it's static and easy to reproduce (just run phase 1 on the config file, or even better, ask the Gradle daemon that's caching the model). On the minus side, it's hard to make out which code in the config is phase-1 and which is phase-2: Same syntax, no static types to guide the intuition; essentially, you have to know which parameters of what phase-1 library functions are closures to be executed in phase 2. Haskell might be able to do better in this area, though I'm in no position to make any proposals for that.