Simon, I am familiar with the GHC library as I had used it a year or so ago to create a very cheap Haddock knockoff. I used the GHC library to do the type inference (which Haddock didn't do at the time) and to deal with elements that didn't have source code available. I remember that I created it specifically because I couldn't get Haddock to work on the GHC API in a useful way. I am looking forward to the result of the SoC project. IIRC, the GHC API needs to be modified to provide (better) support for parsing and typechecking code with syntax errors. That is something that I can probably do when I get to that point. Even if a tool is implemented using the GHC library, it is likely that it would need to limit itself to some subset of GHC's features. For example, an IDE that had a "define instance" feature would need special code to deal with associated types. Similarly, it is better for a tool to refuse to operate on code using implicit parameters rather than (silently) fail to handle them properly, because people tend to hate tools that are really convenienty but occasionally mess up their programs. Regards, Brian On 8/18/06, Simon Peyton-Jones < simonpj@microsoft.com> wrote:
Brian
Great!
You might like to consider using GHC as a library
http://haskell.org/haskellwiki/GHC/As_a_library
The advantage is that you just "import GHC" and then you can parse all of Haskell (including GHC's extensions). Then you can rename it to resolve lexical scopes, typecheck, and so on. It will certainly deal with all of Darcs… because GHC compiles Darcs.
It's all supposed to be a good basis for tools that consume and analyse Haskell programs, which is exactly what you propose to do. Example, there's a summer-of-code project to use it for Haddock.
That said, the API is really just what we needed to build GHC itself. It needs a serious design effort. One of the things that would motivate such an effort would be "customers" saying "I needed to do X with the API and it was inconvenient/impossible". Still, it does work, today.
Simon
*From:* haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] *On Behalf Of *Brian Smith *Sent:* 17 August 2006 17:01 *To:* haskell-cafe@haskell.org *Subject:* [Haskell-cafe] Description of Haskell extensions used by FPTOOLS
Is there any design document for the FPTOOLS libraries or some description of language features that are (allowed to be) used in them?
I am going to be taking some significant time off from my normal jobs in the upcoming months. During part of that time, I would like to do some work to improve the Haskell toolchain. This involves creating or improving tools that parse and analyze Haskell code. My goal is to have these tools support enough of Haskell to be able to handle at least the most important libraries used by Haskell programmers. In particular, this includes all or most of the libraries in FPTOOLS. Plus, I want these tools to operate on Darcs as it is an obvious poster-child for Haskell. Thus, I need to support Haskell 98 plus all the extensions being used in Darcs and FPTOOLS as of approx. March, 2007 (as I intened to start working again at that time).
It would be very nice if there was some document that described "Haskell 98 plus all the extensions being used in Darcs and FPTOOLS as of March, 2007." Besides being useful to me, it would be a useful guide for potential contributors to FPTOOLS.
Regards, Brian