David McBride writes:
While I would personally love having a package description in haskell, I don't think it is a good idea.
I think we all can agree, that using the fully-fledged language for configuration is an extremely bad idea from many perspectives. The worst of all, IMO, is that it makes reasoning about the configuration equivalent to the halting problem. 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. However. 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. After all JSON was born in roughly this spirit, wasn't it? The wins are obvious to me: - the syntax is immediately obvious to the target audience - minimum effort to get existent Haskell tools to work with the "new" format at the source level -- syntax highlighting, checking, etc. The only required additions would be restriction enforcement - no third-party libraries need to be used as dependencies for our core tooling
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.
I remember trying to get started in scala and having a lot of trouble with sbt because I didn't know their operators for lists and arrays or hash tables or whatever it is that they use in their files.
That is because they committed to the sin of employing the whole of Scala for the thing. Bad for them. But also.. let's not commit the mistake of conflating the surface syntax and the semantics. The semantics are dictated by need -- whose sharpening effect on the learning curve is unavoidable. I'm willing to argue that a large part of your confusion came from the /semantics/ of sbt, not the syntax. The syntax differences, OTOH, can and ought to be trivialized. -- с уважениeм / respectfully, Косырев Сергей