Here are some ideas of varying quality: 1. Improvements to GHC unicode support
I've been thinking about unicode lately, since our support could be considerably improved (see http://hackage.haskell.org/trac/ghc/ticket/4855, http://hackage.haskell.org/trac/ghc/ticket/5061, http://hackage.haskell.org/trac/ghc/ticket/3309, http://hackage.haskell.org/trac/ghc/ticket/3308, http://hackage.haskell.org/trac/ghc/ticket/3307). This project could involve: * Implementing PEP-383 like behaviour for GHC's string types * .. which means we could safely decode environment variables/command line arguments (among other things) by default, as people expect * Also valuable would be resolving my "discussion points" at http://hackage.haskell.org/trac/ghc/ticket/5061. This might involve making a proposal to update to the FFI spec with support for TextEncoding * Implement support for double-byte code pages on Windows? * Could also look at http://hackage.haskell.org/trac/ghc/ticket/3569 Should consult with GHC HQ first to see if they would be happy to apply changes along these lines. 2. Implement stack traces See http://hackage.haskell.org/trac/ghc/ticket/3693 My pet project :-). Unfortunately, it's quite hard and I don't feel qualified to mentor it. You might get some useful ideas by looking at the list of feature requests on GHC Trac by priority: http://hackage.haskell.org/trac/ghc/report/3 Cheers, Max 2011/4/1 Gábor Lehel <[email protected]>: > Hi all, > > In case not everyone reads -cafe religiously, I was wondering if > anyone had any interesting GHC-related SoC projects in mind (for > someone with not much prior GHC experience)? I'd definitely like to > apply for a project this year, and I would especially like to work on > GHC. > > The sum total of my GHC experience to this point is writing a small > patch to add GADT support to Template Haskell, which was subsequently > rewritten by SPJ before being committed. That said, hopefully I'd be > able to pick things up fairly quickly -- learning about GHC is half > the reason I want to apply. (The other half, of course, being to > implement something cool for it.) > > The ideas I've managed to think of so far[1] were integrating TH > functions to derive instances with the standard 'deriving' syntax, > adding FFI support for C structs / Haskell tuples, and adding FFI > support for a useful subset of C++ (no templates, etc.), but I'm not > married to any of them (barely even dating). Not knowing GHC very well > I'm also having trouble estimating whether the size/scope of various > potential projects would be appropriate. > > Any ideas or advice would be much appreciated. > > Thanks, > ~g > > [1] -cafe thread: > http://www.haskell.org/pipermail/haskell-cafe/2011-April/090676.html > > -- > Work is punishment for failing to procrastinate effectively. > > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
