[Haskell-cafe] Standard package file format

[Herbert Valerio Riedel]

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