[Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)

[Thomas Schilling]

On 17 December 2011 05:39, Gregory Crosswhite <gcrosswhite at gmail.com> wrote:

>
> On Dec 17, 2011, at 9:58 AM, Thomas Schilling wrote:
>
> 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).
>
>
> So in other words, would it be helpful it we recruited GHC janitors?  That
> is, similar to how we have the Trac which gives people bug reports to pick
> out and work on, would it make sense to have a Trac or some other process
> which gives people chunks of code to clean up and/or make easier to test?
>
> (I am of course inspired in suggesting this by the Linux kernel janitors,
> though it doesn't look like the project has survived, and maybe that
> portends ill for trying to do the same for GHC...)
>

I'm not sure that would work too well.  GHC is a bit daunting to start with
(it gets better after a while) and just cleaning up after other people is
little fun.  I would be more interested in setting up a process that
enables a clean code base (and gradually cleans up existing shortcomings).
 Of course, I'd prefer to do rather than talk, so I'm not pushing this at
this time.  At the moment, I think we should:

 1. Find a plan to get rid of the existing bigger design issues, namely:
the use of global variables for static flags (may require extensive
refactorings throughout the codebase), the use of nondeterministic uniques
for symbols (may cost performance)

 2. Build up a unit test suite (may include QuickCheck properties).  The
idea is that if our code needs to be tested from within Haskell (and not
the just the command line) then that encourages a design that can be used
better as a library.  It may also catch some bugs earlier and make it
easier to change some things.  (Note: the high-level design of GHC is
indeed very modular, but the implementation isn't so much.)

 3. Set up a code review system.  Every commit should have to go through
code review -- even by core contributors.  Even experienced developers
don't produce perfect code all the time.  Currently, we have some
post-commit review.  A possible code review system for Git is Gerrit.

Of course, the GHC developers would need to get on board with this.  As I
said, I currently don't have the time to pursue this any further, but I'm
planning to apply this to my projects as much as possible.

 / Thomas
-- 
Push the envelope. Watch it bend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111218/f7b26917/attachment.htm>