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.
if, for instance, you run the above through a YAML pretty-printer, you easily end up with something like
when: - else: ghc-options: -O0 then: ghc-options: -O2 condition: flag(fast)
or any other ordering depending on how the keys are sorted/hashed.
Only if you use a bad pretty-printer that parses the YAML, then writes it in prettified form. Such a pretty-printer would also lose comments. In other words: I'd be surprised to find a pretty-printer in actual use that works that way.
Besides, many YAML (& JSON) parsers silently drop duplicate keys,
That's indeed a common bug/misfeature due to historical accidents. It's easy to fix though, and libraries have started to acquire options to get that reported as an error.
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.