Thanks a lot for your comprehensive response, Claus!Per your suggestion, I started a GHC wiki page at http:// hackage.haskell.org/trac/ghc/wiki/GhcApiStatus.
I added your comments and I will continue to add more things as I find them.
I am closely following the Yi project and I am aware that the HaRe project needs some help from my side. I am interested that both projects become more usable and useful, so I'll be looking forward to concrete requests from both sides.
I am also aware of Max's project. We certainly have to look out not to get into each other's ways but as I understand it Max will work on lower-level transformations, while I will concentrate on the front- end. We should therefore be able to keep our work fairly separate.
thanks, I was wondering about your project. Is there a project page documenting the issues/tickets you look at, and particularly the plan of attack as it changes in the face of reality?-) I've foundhttp://code.google.com/soc/2008/haskell/appinfo.html? csaid=4189AF2C8AE5E25Awhich covers a lot of ground, and some interesting issues, but is so general (and design- rather than application-driven) that I've been worried about how much of it you'll manage (and with which priorities), given that the GHC API is indeed exposed rather than designed and may thus interfere with your good intentions in unexpected ways.
Yes, I tried to comment on this a little on the wiki page. I will also do an internship at MSR beginning in October. The topic isn't decided upon, yet, but working on the GHC API was among the things I proposed.
Also, there are very different user needs out there, some want just analysis or some information extraction, some want source transformation capabilities, some want a stable portable hs-plugins replacement, some want to work with backends, etc. . you can't please everyone, but until your focus is known, people can't easily complain about your priorities.
I will start with extracting semantic information from Haskell code. Things that are useful for Yi or HaRe. But if people give good arguments for other features I'd be willing to change priorities. Of course, Simon will have a word there, too. :)
IMHO, trying to support a semantics- and comment-preserving roundtrip in (pretty . parse) would be a good way to start (David says he's going to look at the extracting comments/pragmas part,but they still need to be put back in during pretty printing). It soundssimple, and if it is, it will enable a lot more usage of the GHC API; and if it turns out not to be simple, you'll have a first sign of what you're up against, and can adjust your expectations!-)
I agree. This looks like a good getting-up-to-speed topic.
Making yourself available as you've done here "I'm here; I'm going to work on this now; please cc me if you want to express your priorities" sounds like a good way to pull together the many strands of interests relating to the GHC API. Now we all have to dust off our old "wouldn't it be nice if the API could do this and that"s.
I'm looking forward to a lot of those responses, and I will try and dig around in the archives to find some of those myself.
/ Thomas
--My God's will / becomes me. / When he speaks out, / he speaks through me. / He has needs / like I do. / We both want / to rape you.
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
