Another factor in favor of YAML is that it is a superset of JSON, which eases the learning curve even more (with JSON being a de facto lingua franca for cross-platform untyped data structures), and offers some extra possibilities, although I admit that I can't think of any practical uses. The fact that both Yaml and JSON can be represented as Aeson Values would also make things (arguably) easier for tool writers. On Sep 16, 2016 8:20 AM, "Harendra Kumar" wrote:

I am starting a new thread for the package file format related discussion.

From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways.

Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem.

I gather the following from the discussion till now:

* We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools.

* cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it.

* 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.

* TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption.

As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files.

More thoughts, opinions on the topic will help create a better understanding about it.

-harendra

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I guess the overriding question I have here is: what is the PROBLEM being solved? I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format. It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc. But the syntax? It's just not an issue. I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment. With this in mind, a lot of the statements about these various languages are not entirely convincing. That it's a superset of JSON? It's not clear why this matters. A psychological impression of complexity? Just not anything I've seen evidence of. Indeed, aside from the rather painful many-years-long migration, the *cost* (though certainly not a prohibitive one) of moving to something like YAML or TOML is that they have a bit louder syntax, that demands more attention and feels more complex. There is one substantial disadvantage I'd point out to the Cabal file format as it stands, and that's that it's pretty non-obvious how to parse it, so we will always struggle to interact with it from automated tools, unless those tools are also written in Haskell and can use the Cabal library. That's a real concern; pragmatic large-scale build environments are not tied to specific languages, and include a variety of ad-hoc third-party tooling that needs to be integrated, and Cabal remains opaque to them. But that doesn't seem to be what's motivating this conversation. On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar wrote:

I am starting a new thread for the package file format related discussion.

From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways.

Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem.

I gather the following from the discussion till now:

* We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools.

* cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it.

* 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.

* TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption.

As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files.

More thoughts, opinions on the topic will help create a better understanding about it.

-harendra

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

(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

I haven't totally followed this whole thread, so apologies if this isn't entirely relevant, but I use shake for building, and cabal for dependencies. The shakefile has the list of packages and required versions, and generates the .cabal file, which is used with --only-dependencies to get dependencies. I think it works well. I can't do builds in cabal anyway since it can't handle anything complicated, but even if I had a simple build I'd prefer shake since it's so much nicer. Since it's in haskell, it's flexible but can't be analyzed, though I can't think of why you'd want to analyze it. Meanwhile, cabal is just fine at expressing packages and versions, and is basically just a way to tell cabal-install what to download and install. Since I generate it, I don't care much about the format, but the existing one seems perfectly adequate.