[Haskell-cafe] Standard package file format
cdsmith at gmail.com
Fri Sep 16 08:24:41 UTC 2016
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
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 <harendra.kumar at gmail.com>
> 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
> * 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
> More thoughts, opinions on the topic will help create a better
> understanding about it.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe