Am 16.09.2016 um 15:37 schrieb Kosyrev Serge:
The worst of all, IMO, is that it makes reasoning about the configuration equivalent to the halting problem.
That's a solved problem: Generate an execution plan, which would need to be fully evaluated in Haskell; then execute it and don't feed anything back into it. It's easy to reason about the plan in that scenario. This is what Gradle does.
And god, does it hurt in practice! -- speaking as someone who had spent a non-trivial amount of time on doing exactly this stuff in another age and for another language.
Which language?
This does not mean that we cannot find a subset of the language that would be a point of balance between the needs of expressivity, learnability and decidability.
Subsettings makes it hard to know what works and what doesn't. A Haskell subset would have to be strict - which begs the question what's the point in calling this a subset of Haskell (and even if there is a point, it will draw ridicule along the lines of "Haskell is unsuitable for describing its own configurations").
After all JSON was born in roughly this spirit, wasn't it?
JSON was/is a serialization format, first and foremost.
If you can't start or modify a package without already knowing haskell, it is a huge barrier to entry.
I'm unconvinced that this problem cannot be resolved within the subsetting approach.
Actually subsetting is making this worse: Things freshly learned for Haskell won't work in the config language, restrictions encountered in the config language will be unthinkingly transferred to Haskell. Having two subtly but fundamentally different languages is about the worst thing you can expose a learner to.