<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-09-18 19:38 GMT+02:00 Imants Cekusins <span dir="ltr"><<a href="mailto:imantc@gmail.com" target="_blank">imantc@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">yes, .hs AST etc must be implemented.</div></div></div></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"> However implementing cabal in addition to that is more work.<br></div></div></div></blockquote><div><br></div><div>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.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>> Distinct from what?</div><div> from .hs. </div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>> [attention] >From whom?</div><div>IDE devs</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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></span><div>if serialized model is used, </div><div>then parsing, update, validation, formatting are no longer necessary</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><div></div></span></div></div></div></blockquote><div><br></div></span><div>What standard package format are we trying to agree then?</div></div></div></div></blockquote><div><br></div><div>stack.yaml is not a "package format", so there is nothing to agree on.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><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></span><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><span class=""><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></span><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></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>If this may be avoided, why not at least consider this as an option?</div><span class=""><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><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></span>Standard package file format (as the thread is called). Isn't it about cabal and yaml?</div></div></div></blockquote><div><br></div><div>If we are really only talking about a *package* format, there is currently only .cabal and a single format is by definition "standard". :-)</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div>well if config is expressed in terms of Haskell syntax, implemented .hs support will be enough to support editing these config files. <br></div></span><div>Each file type (including .cabal) takes time to implement.</div></div></div></div></blockquote><div><br></div><div>Again: Where is that ominous ".hs support" coming from?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></ul></div></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul><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></div></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Am I the only one who sees these as issues that need / can be solved?<br></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></blockquote><div><br></div><div>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?)</div></div></div></div>