On Thu, Dec 15, 2011 at 6:24 PM, Thomas Schilling <span dir="ltr">&lt;<a href="mailto:nominolo@googlemail.com" target="_blank">nominolo@googlemail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

What exactly are the hopes for such a type checker?  I can understand<br>
it being interesting as a research project, but as a realistic tools<br>
there are two huge issues:<br>
<br>
 1. It&#39;s going to take a LOT of time to reach feature parity with<br>
GHC&#39;s type checker.<br>
<br>
 2. Assuming that can be done, how is it going to be maintained and<br>
kept up to date with GHC?<br>
<br>
If it is going to be used as a development tool, both of these are a<br>
major requirement.  I haven&#39;t looked into the issues, but I&#39;d expect<br>
it would be more realistic (although definitely not trivial) to<br>
translate from GHC&#39;s internal AST into an annotated haskell-src-exts<br>
AST.<br>
</blockquote><div><br></div><div>With all due respect, the sentiments you give voice to here are a large part of what drives me to do this project in the first place. Haskell is not GHC, and I think that the very dominant position of GHC many times leads to ill thought-through extensions. Since GHC has no competitor, often extensions (meaning behavior as denoted and delimited by some -X flag) are based on what is most convenient from the implementation point of view, rather than what would give the most consistent, logical and modular user experience (not to mention third-party-tool-implementor-trying-to-support-GHC-extensions experience).</div>
<div><br></div><div>As such, I&#39;m not primarily doing this project to get a development tool out, even if that certainly is a very neat thing. I&#39;m just as much doing it to provide a Haskell (front-end) implementation that can serve as a better reference than GHC, one that very explicitly does *not* choose the convenient route to what constitutes an extension, and instead attempts to apply rigid consistency and modularity between extensions. Also, just like for haskell-src-exts I hope to build the type checker from the roots with the user interface as a core design goal, not as a tacked-on afterthought.</div>
<div><br></div><div>Mind you, in no way do I intend any major criticism towards GHC or its implementors. GHC is a truly amazing piece of software, indeed it&#39;s probably my personal favorite piece of software of all times. That does not mean it comes free of quirks and shady corners though, and it is my hope that by doing what I do I can help shine a light on them.</div>
<div><br></div><div>Answering your specific issues: </div><div><br></div><div>1) Yes, it&#39;s a lot of work. Probably not half as much as you&#39;d think though, see my previous mail about walking in the footsteps of giants. But beyond that, I think it&#39;s work that truly needs to be done, for the greater good of Haskell.</div>
<div><br></div><div>2) Well, I think I&#39;ve done a reasonably good job keeping haskell-src-exts up to date so far, even if the last year has been pretty bad in that regard (writing a PhD thesis will do that to you). I&#39;ll keep doing it for the type checker as well. But I am but one man, so if anyone else feels like joining the project then they are more than welcome to.</div>
<div><br></div><div>Sort-of-3) Yes, both implementation and maintenance are likely going to be far more costly than the alternative to do a translation via the GHC API. I&#39;m not interested in that alternative though.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>/Niklas</div>