[Haskell-cafe] Standard package file format

Joachim Durchholz jo at durchholz.org
Fri Sep 16 13:51:48 UTC 2016

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.

More information about the Haskell-Cafe mailing list