[Haskell-cafe] Standard package file format

[Sven Panne]

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

> yes, .hs AST etc must be implemented.
>

If we're talking about a Haskell tool, it *is* already implemented: Just
look into the Cabal project on github. If we're not talking about a Haskell
tool and something outside the cabal/hackage/stackage ecosystem, writing an
AST and a parser for it will be the least of your problems: The main
problem will be how to map cabal's/stack's view what is a package/project
to your tool's view. I don't think there's an universally agreed upon
notion of what is a package or project, almost every IDE out there has its
own view of what those mean, each with its pros and cons (which may be
heavily influenced by the package/project programming language, not the
language in which the IDE is written).


> However implementing cabal in addition to that is more work.
>

Are we talking about parsing/printing here? If yes, there's already work in
that direction (making the frontend, i.e. parser/printer/AST, a separate
library), at least that's what I understood so far.


> > Distinct from what?
>  from .hs.
>

And that's perfectly fine: A project/package description is something
fundamentally different than a turing-complete general-purpose programming
language. A project/package description should be a mostly static,
declarative thing, perhaps with a few conditionals and/or (hygienic) macros
or such for convenience/brevity, but not something which can calculate
fibonacci numbers or solve differential equations.


> > [attention] From whom?
> IDE devs
>

Hmmm, so parsing some package/project description is a problem when writing
an IDE? I highly doubt that this is relevant compared to the amount of work
needed for an average IDE.


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

Huh? What's a "serialized model" then? Whatever you do, you have to
parse/validate/... any description. Even if you choose some subset of
Haskell (which is probably a bad idea IMHO because it's either too general
or not really Haskell anymore), there has to be *some* parser etc. Where
should that come from? Neither Emacs nor VIM can e.g. parse/print Haskell
out of the box, VS probably can't either.


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

stack.yaml is not a "package format", so there is nothing to agree on.


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

stack.yaml is not .cabal in a new syntax, there is new functionality. Even
if both were e.g. written in YAML, your shiny hypothetical IDE wouldn't
suddenly support reproducible multi-package builds out of the box if it
couldn't do so before.


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

If we are really only talking about a *package* format, there is currently
only .cabal and a single format is by definition "standard". :-)


> 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: Where is that ominous ".hs support" coming from?


> the problems as I see them are:
>
>    - users need to learn .cabal (.yaml, ...) syntax in addition to .hs
>    syntax
>
> As has already been mentioned by others, I *highly* doubt that the .cabal
syntax itself poses the slightest problem for anyone. The semantics are a
different story, but you have to learn them anyway.

>
>    - IDE need to implement each such syntax on top of .hs. That is, if
>    support / sync of these configs to code files is expected.
>
> You just update your internal view of the package/project and write out
the changed part. With library support for .cabal and YAML files that's
trivial.

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

That's the central question IMHO. :-) The current discussion seems to drift
towards: Do we need the current package/project dichotomy or can we throw
everything together? (Note that e.g. Visual Studio distinguishes projects
and solutions, too, perhaps there's a reason for that?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160918/53680252/attachment.html>