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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
