<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">> 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. <br><br>yes, .hs AST etc must be implemented. However implementing cabal in addition to that is more work.<br> <div>> Distinct from what?</div><div> from .hs. </div><div> </div><div>> [attention] From whom?</div><div>IDE devs</div><div> </div><div>>> It  needs to be parsed, updated, validated, formatted.</div><div>> 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.</div><div><br></div><div>if serialized model is used, </div><div>then parsing, update, validation, formatting are no longer necessary</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><span class="gmail-"><div></div></span></div></div></div></blockquote><div><br></div><div>What standard package format are we trying to agree then?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> More problems (distinct file type etc).</div></div></blockquote><div><br></div></span><div>What are the actual problems here?</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> More formats may follow.</div></div></blockquote><div><br></div><div>If they are for different purposes, that's OK and is to be expected.</div></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>If this may be avoided, why not at least consider this as an option?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> .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?</div></span></div></div></div></blockquote><div><br></div><div><br></div>Standard package file format (as the thread is called). Isn't it about cabal and yaml? </div><div class="gmail_quote"><br></div><div class="gmail_quote">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?<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div></div></div></div></blockquote><div><br></div><div>well if config is expressed in terms of Haskell syntax, implemented .hs support will be enough to support editing these config files. </div><div>Each file type (including .cabal) takes time to implement.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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).</div></div></div></div>
</blockquote></div><br></div>adopting standard package file format. Which could be  addressed even better by adopting typed standard config content.<div><br></div><div>the problems as I see them are:</div><div><ul><li>users need to learn .cabal (.yaml, ...) syntax in addition to .hs syntax</li><li>IDE need to implement each such syntax on top of .hs. That is, if support / sync of these configs to code files is expected. </li></ul><div><br></div><div>Am I the only one who sees these as issues that need / can be solved?</div></div><div><br></div><div>Also maybe let's be more specific: what is this thread - <u>Standard package file format</u> - all about?</div></div>