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" <harendra.ku...@gmail.com> 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.
>
_______________________________________________
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Reply via email to