On Mon, Jul 5, 2010 at 1:39 AM, John Smith <volderm...@hotmail.com> wrote:
> None of the frameworks in > http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries#High-levelappear > to have a working build in > http://hackage.haskell.org/packages/archive/pkg-list.html#cat:gui, except > wxFruit. Is there a need that isn't being met for "high-level" GUI > libraries? > > Another suggestion I received in a private reply is to work on data > persistence, but it would be tough to evaluate all the dozens of entries in > http://hackage.haskell.org/packages/archive/pkg-list.html#cat:database. Is > there some database need that isn't being met? > > I've never done serious Haskell programming (I've played with it a little > while doing lots of C# at work), so I'm hoping that more experienced Haskell > programmers could identify a potentially useful contribution. Have you looked over Don's list of suggested summer of code projects? These were the suggested ones by Don: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gsoc-projects/ Here are the ones that were actually accepted: http://donsbot.wordpress.com/2010/04/26/the-7-haskell-projects-in-the-google-summer-of-code/ It seems like anything from the original list that isn't being tackled would count as an important contribution. Summer of Code is probably a smaller scope than your MSc, but that doesn't strike me as a problem. Typically in any software project, once you start working on it you can easily find room to expand it in useful directions. Similarly with the need for a research component. If you get creative you should be able to find some aspect that others haven't investigated. One thing I've been wanting lately is a good client / server, meeting scheduling / calendaring / time tracking software. Something along the lines of Meeting Maker or iCal, but open source, extensible, and with the polish of Google Calendar. I've been thinking about it a lot and I have several other usability ideas to throw in to make it really shine. I keep meaning to post my requirements on my blog. Maybe I'll get to that this week. Another thing I'd like, is to augment GHC with a type level debugger. One simple idea I had for that was to have GHC dump out the source code it's type checking with the types it has figured out (and the ones that don't type check, expect vs. inferred) annotated at every term and subterm. This has some technical hurdles, but mainly I think it has usability concerns to address. For example, how to let the user zoom in to the smallest term and see the type while also letting them select larger terms and see the type, all without being overwhelmed. Something that novices can make sense of but experts enjoy using too. Here is another idea. I'd like to see more integration between personal wikis (ones you run on localhost) and email systems. Imagine that an email comes into your inbox and then you can annotate the email by adding notes, sort of like track changes in Word. The email + notes stays in your inbox. It would be nice if you could bookmark those emails too in your web browser or similar. This would be handy for me as I sometimes reference specific emails for a long time and I often want to make notes as I reference them. Currently I paste the email into gitit and go for there. A universal interface / adapter for version control systems would be nice, but I think this one needs more research. We currently have a problem with vcs that each one speaks its own language. To me this is analogous to only being able to email people who use the same email client as you. Quite suboptimal. I hope that helps, Jason
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe