[Haskell-cafe] Description of Haskell extensions used by FPTOOLS

[Brian Smith]

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 at 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 at haskell.org [mailto:haskell-cafe-bounces at haskell.org]
> *On Behalf Of *Brian Smith
> *Sent:* 17 August 2006 17:01
> *To:* haskell-cafe at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell-cafe/attachments/20060822/95e8b7c3/attachment-0001.htm