On Fri, Sep 16, 2016 at 4:35 PM, Imants Cekusins <imantc@gmail.com> wrote:

> Would cabal-install need to link in all these maintained libraries statically? Or would there be some plug-in mechanism to load them on demand?

well the libraries would need to be official and some with the packager.

the formats would be perfectly interchangeable i.e.
cabal -> standard_type -> yaml -> standard_type -> json -> standard_type -> cabal
would produce the same cabal file

only 1 config file per package to avoid confusion

however if the user prefers working with format F, they can always convert the format which came with the package, to F

Even just looking at the set of features which is 1:1 betw. YAML and JSON, we're essentially just talking about key-value pairs with a couple of common types for the values. This isn't all .cabal files contain (e.g. see hvr's points about conditionals), but if it were true, is it really worth changing how Cabal works for a diffferent color bikeshed?

On Sat, Sep 17, 2016 at 8:06 AM, Imants Cekusins <imantc@gmail.com> wrote:

> Do I have to obtain whatever whizzy new controller you've come up with in order to work with your packages?
> Do I have to do this when everyone has come up with their own whizzy new controller and I need to fit their packages into whatever I am trying to write?

that's the while point. If we could agree on a standard serializeable model, each controller would ensure the link between the view and the model.

user could open a package in any IDE / environment. The environment's controller would display the model in its own / user preferred view.

Why not have .cabal files be the standard model, and anyone can write tools on top to translate to/from .cabal if users really want to use something else?

In general, though, I don't think the fragmentation is worth it.

Tom