How to start with GHC development?

[Gershom Bazerman]

On 12/14/12 9:44 AM, Simon Peyton-Jones wrote:
>
> This thread has made it clear that we should do more to help people 
> find a "way in" to GHC.  Here is what I have done:
>
> ·Started a GHC Reading List page 
> <http://hackage.haskell.org/trac/ghc/wiki/ReadingList>, giving 
> background reading.  It's just a start; there are many gaps. I would 
> love it if you would all help fill it out.  It's a wiki.
>
> ·Amplified the Working on GHC 
> <http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions> page.  
> Again, please help make it more useful. It's a wiki.
>
> What else would help?   If the answer is X, can anyone help do X?
>
>
Something else that I think would be useful is a long-term 'wishlist' 
for ghc, consisting of modest goals from an engineering standpoint. My 
sense is that these involve factoring subsystems to make them more 
independent and modular, as well as moving towards parallelizable code, 
and perhaps the notion of ghc-as-a-service so that one could have a 
long-running compiler process able to perform individual parts of a 
pipeline on-demand. The scheme of what needs to change and overall 
architecture needs to be determined by people with very good knowledge 
of the compiler as a whole. But individual tasks and areas could be 
tackled by others wishing to contribute.

I'd also like more of a sense of what work remains to be done to 
decouple ghci from ghc, such that we could pleasantly produce other 
ghci-like environments using the same API, and perhaps ultimately treat 
desktop ghci as one means among many of interacting with 
ghc-as-a-library. (i.e. how can we get to 'cabal install ghci').

I'm also curious about the state of the plugins pipeline, how 
comfortable we are with it, and what could potentially be improved (and 
how that relates to having ghc potentially process externally generated 
or transformed core).

This is to say, outside of the list of bugs on trac, and outside of 
potentially researchy new features, what are the sorts of things we 
would like to make GHC a more dependable, efficient, maintainable, 
flexible piece of software? The things I'm suggesting a focus on are 
things that I remember discussion of along these lines. They're perhaps 
not where core GHC developers feel effort should be focused. But where 
then *should* it be?

A sense of this might help interested contributors to decide where to 
direct their efforts.

Thanks,
Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121214/a524f52c/attachment-0001.htm>