Hello, On 2016-09-17 at 08:41:37 +0200, Joachim Durchholz wrote:
Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel:
the prospect that a standard format like YAML would allow to reuse standard tooling/libraries for YAML seems quite weak to me;
It's not about standard tooling, it's about tools written by third parties. Tools that you didn't have the time or interest to write yourself, but which still help make your ecosystem more useful to others.
Sure, but we don't need to throw out the baby with the bathwater to accomplish that! Oleg is currently working on a new parser for cabal.config, cabal.project & ${pkg}.cabal grammar (NB: cabal already uses one standard unified syntax for all its configuration/description files) which lends itself better to provide equivalent of ghc-exactprint (i.e. perfect roundtripping, allowing for faithful refactoring tooling). Then 3rd parties can then use this new parser as a library. [..]
I really don't understand the appeal of applying the golden hammer of YAML, if `.cabal`'s grammar is already self-evident and concise with its syntax:
if flag(fast) ghc-options: -O2 else ghc-options: -O0
where this if/then/else construct is encoded in the grammar proper rather than being merely a semantic interpretation after decoding a general grammar designed for simpler typed data-representations which isn't even accurate enough (since it has additional symmetries/freedoms) to capture the desired grammar faithfully, which make YAML quite error-prone for this specific application.
Yeah it isn't nice. Changing the grammar always produces that kind of awkwardnesses. However, for a fair comparison, you need to actively look for things that work better with the alternate grammar before you conclude it's worse.
Well, that burden of proof lies with those who argue YAML to be superior to .cabal syntax, doesn't it? The if/then/else awkwardness is just one aspect I pointed out explicitly. I hinted at other issues which result from first parsing into an inappropriate data-model just for the sake of using YAML, and then having to re-parse that interim lossy data-model for real into the actual data-model we're interested in (and hoping we didn't loose some of the essential information). But I see no need to invest time to spell those problems out until I see a compelling argument that e.g. YAML syntax is really preferable (to justify the costs incurred) to the status quo in the first place. -- hvr