[Haskell-cafe] Standard package file format

[Sven Panne]

2016-09-18 17:40 GMT+02:00 Imants Cekusins <imantc at gmail.com>:

> .cabal file is representation rather than a model. It is parsed to model.
>

Well, that's the case for basically everything you give to a program, so I
don't see the point here. A .hs file is e.g. just a textual representation
of the more abstract notion of a Haskell program/module, too. A .cabal file
is just a textual representation of a the abstract notion of a Haskell
package description.


> Being a distinct file type with its own AST,
>

Distinct from what?


> it needs quite a bit of attention.
>

>From whom?


> It  needs to be parsed, updated, validated, formatted.
>

This will be the case for whatever is being used, so again: What's the
point? It doesn't matter if it's in its own .cabal syntax, in some
Haskell-like syntax, JSON, YAML, or even some graphical representation.


> Another config format emerged.
>

I'm not sure what config format is meant here. If it's stack.yaml, it
*must* be somehow different (even if we ignore the surface syntax), because
it describes a project, not a single package.


> More problems (distinct file type etc).
>

What are the actual problems here?


> More formats may follow.
>

If they are for different purposes, that's OK and is to be expected.


> Is there hope to agree on common format (as per thread title), if common
> content can not be agreed on? Isn't config first of all about content? Is
> the common format going to contain incompatible / conflicting data items?
>

.cabal files describe "how a package looks like" and a stack.yaml describes
"how to build a project in a reproducable way", which are different
(although related) things. What should "common" mean here?


> With common content, display format will not matter at all, neither will
> package tool nor IDE used to work on a project.
>
> Config being a Haskell type, it would be well formed. The options would be
> well known.
>
> Users and IDE devs will not need to worry about indenting, commas, line
> breaks and other *goodies*.
>

Somehow you will always need a concrete representation of abstract notions
(call them "models", "ASTs", etc.), otherwise you won't be able to process
them. So you will always need to care about some kind of syntax etc., I
can't see how using a "Haskell type" will help here. And you will need some
semantics for the representation. Even if we used e.g. JSON (or whatever is
en vogue at the moment), IDEs will not magically start understanding and
supporting Haskell projects.

Again: What is the actual problem we're trying to solve? I still haven't
seen a concrete use case which is hard/impossible with the current state of
affairs. Personally, I would e.g. like to see some abstraction facilities
to avoid repetition in .cabal files with lots of executables, but I don't
care about the concrete syntax (and Cabal's internal model/AST wouldn't be
affected, either).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160918/858a27ad/attachment.html>