[Haskell-cafe] Standard package file format

[Herbert Valerio Riedel]

(resent from different account, sorry if dupe)

On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote:

[...]

> * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A
> significant chunk of developer community is already familiar with it. It is
> being used by stack and by hpack as an alternative to cabal format. The
> complaint against it is that the specification/implementation is overly
> complex.

I'm not sure if this has been pointed out already, but beyond turning a
proper grammar into a stringly-typed one, shoehorning some features of
.cabal files into YAML syntax really appear like a case of the "Genius
Tailor"[1], e.g. consider the `hpack` example

   when:
     - condition: flag(fast)
       then:
         ghc-options: -O2
       else:
         ghc-options: -O0

besides looking quite awkward IMHO (just as an exercise, try inserting a
nested if/then/else in that example above), the prospect that a standard
format like YAML would allow to reuse standard tooling/libraries for
YAML seems quite weak to me; 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.

Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if
by accident you place a 2nd `else:` branch somewhere, you end up with an
ambiguous .yaml file which may either result in an error, in the first
key getting dropped (most likely variant), or in the 2nd key getting
dropped. Which one you get depends on the YAML parser implementation.


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.



 [1]: The "Genius Tailor" was mentioned recently in a related discussion here:
      https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html

-- hvr