On 16 December 2011 17:44, Niklas Broberg
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).
I agree. Various record proposals have been rejected because of the "not easily implementable in GHC" constraint. Of course, ease of implementation (and maintenance) is a valid argument, but it has an unusual weight if GHC is the (in practise) only implementation. Other extensions seem to just get added on (what feels like) a whim (e.g., RecordPuns).
As such, I'm not primarily doing this project to get a development tool out, even if that certainly is a very neat thing. I'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.
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'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.
Weeeell... I've gotten a little bit of a different perspective on this since working at a company with very high code quality standards (at least for new code). There is practically no observable code review happening. I'm sure Dimitrios and Simon PJ review most of each other's code every now and then, but overall there is very little code review happening (and no formal, recorded code review whatsoever). Cleaning up the GHC code base is a huge task -- it uses lots of dirty tricks (global variables, hash tables, unique generation is non-deterministic, ...) which often complicate efforts tremendously (I tried). The lack of a unit tests doesn't help (just rewriting code so that it can be tested would help quite a bit). Don't get me wrong, I certainly appreciate the work the GHC team is doing, but GHC strikes a fine balance between industrial needs and research needs. I'm just wondering whether the balance is always right.
Answering your specific issues:
1) Yes, it's a lot of work. Probably not half as much as you'd think though, see my previous mail about walking in the footsteps of giants. But beyond that, I think it's work that truly needs to be done, for the greater good of Haskell.
Right OutsideIn(X) (the Journal paper description, not the ICFP'09 version) seems like the right way to go. I wasn't aware of the other paper (the original work on bidirectional type inference seemed very unpredictable in terms of when type annotations are needed, so I'm looking forward to how this new paper handles things).
2) Well, I think I'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'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.
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'm not interested in that alternative though.
Fair enough. As I am interested in building reliable (and maintainable) development tools my priorities are obviously different. For that purpose, using two different implementations can lead to very confusing issues for the user (that's why I was asking about bug compatibility). Apart from the bus factor, there is also the bitrotting issue due to GHC's high velocity. For example, even though HaRe does build again it doesn't support many commonly used GHC extensions and it is difficult to add them into the existing code base (which isn't pretty). Anyway, good luck with your endeavours. / Thomas -- Push the envelope. Watch it bend.