> So if you can execute arbitrary code in a new-gen cabal file, apart from
the security aspects, ...
well config files could use different (not .hs) extensions. They could use
their own Prelude and not allow importing other modules.
The main benefit is to reuse existing parsers and simplify
this may be one of the 3 points on Paolo's list. In case it is not, here is
another option (4?):
- define .hs data records for project config, package configs
- write export tools to export config records to existing formats:
cabal
stack yaml
...
this way, there is no need to revise
