Eric Rochester <eroch...@gmail.com> wrote: > Another idea is to have a list of open tasks grouped by how difficult > they will be and how much knowledge of Haskell and GHC will be > required. This is somewhat at odds with the earlier suggestion to have > domains in codebase, with separate de facto maintainers for > each. However, it would make it easier for others to contribute. I > could also see where the domain maintainers could put simpler tasks > into a global index. That might mix the best of both.
It doesn't have to be at odds with the domain suggestion. In fact they can be combined neatly. The maintainer of a domain is the best person to judge the difficulty of a task, so they can assign the difficulty levels. A new GHC developer can then view all tasks from all domains sorted by difficulty and start with the easiest ones. To me this sounds like a great idea to encourage people to join GHC development. I'm very interested myself, as I actually have some experience writing compilers for statically typed lazy languages (including STG compilation), but unfortunately my spare time is very limited. However, I would like to solve at least some easy tasks to get going. As for Simon Marlow's legacy perhaps this is the opportunity to reevaluate the current run-time system and make it more transparent, more modular as well as easier to substitute/customize. This could open the doors to using GHC for low level systems programming up to the point where you can write kernels in Haskell. This is something I am particularly interested in. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
