[Haskell-cafe] Standard package file format

[Imants Cekusins]

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

yes, .hs AST etc must be implemented. However implementing cabal in
addition to that is more work.

> Distinct from what?
 from .hs.

> [attention] From whom?
IDE devs

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

if serialized model is used,
then parsing, update, validation, formatting are no longer necessary


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

What standard package format are we trying to agree then?


>
>
>> More problems (distinct file type etc).
>>
>
> What are the actual problems here?
>

implementing each new file type in IDE is a lot of work. That is, if IDE is
trying to do anything with contents of that file. Such as support syncing
renamed file to config.


>
>
>> More formats may follow.
>>
>
> If they are for different purposes, that's OK and is to be expected.
>

Each new format would need to be implemented. Time spent on implementing
new formats is time not spent on implementing any other features. It may
take nearly as long as implementing .hs support itself. Is this even
thought about?

If this may be avoided, why not at least consider this as an option?


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


Standard package file format (as the thread is called). Isn't it about
cabal and yaml?

Anyway, can not a common config file be used for both purposes? If not, can
common file type / model be used for both purposes - sharing the common
parts of the type structure?



> 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.
>
>
well if config is expressed in terms of Haskell syntax, implemented .hs
support will be enough to support editing these config files.
Each file type (including .cabal) takes time to implement.



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

adopting standard package file format. Which could be  addressed even
better by adopting typed standard config content.

the problems as I see them are:

   - users need to learn .cabal (.yaml, ...) syntax in addition to .hs
   syntax
   - IDE need to implement each such syntax on top of .hs. That is, if
   support / sync of these configs to code files is expected.


Am I the only one who sees these as issues that need / can be solved?

Also maybe let's be more specific: what is this thread - *Standard package
file format* - all about?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160918/0998719b/attachment.html>