API-tracker to check compliance with package versioning policy---advice please?

Isaac Dupree ml at isaac.cedarswampstudios.org
Tue Mar 23 04:06:09 EDT 2010

On 03/22/10 23:43, Damon Wang wrote:
> Hello everyone,
> I'm interested in writing the API-tracker described here
>      http://hackage.haskell.org/trac/summer-of-code/ticket/1565
> Mr. Marlow suggested I discuss it on the mailing list first. If this is
> the wrong list, I'm sorry, and I'd appreciate knowing where to find the
> correct one.


(you could also try libraries at haskell.org , which contains more people)

>> From the package versioning policy here
>      http://www.haskell.org/haskellwiki/Package_versioning_policy
> it seems like the most foolproof way to validate a revised module's
> version number would be to diff the types of each exported symbol.
> There's a previous thread on this list by Laszlo Nagy suggesting

Can you link to it in online archives?

> has the information I need to answer that question, or at least to read
> the GHC API reference. Unfortunately---you guessed it!---I don't know
> enough to understand the commentary.

hmm, I had this issue a bit last year, working on Haddock! But I 
eventually got used to it, by trying to do things with it.  I found it's 
important to also go read the GHC code itself. Often it contains 
comments that didn't make it into the generated Haddockumentation; 
sometimes reading a function's implementation is necessary to guess what 
it does.  Maybe you could find another project that uses the GHC API on 
types, and try to understand it? (for example, Haddock's code breaks up 
some version of the types in order to display them in docs, although I 
suspect it may be a less-processed, closer-to-source-syntax version than 
you'd want for actually comparing two types with each other).  etc... 
And the Commentary is pretty good once you know enough (and some of the 
pages are overviews of the compiler pipeline...)

and for ghc-specific questions, glasgow-haskell-users at haskell.org (or 
cvs-ghc at haskell.org sometimes for technical GHC-internals is alright)

also, just lurking and reading relevant mailing-lists where other people 
are trying to solve their own problems relating to GHC: sometimes this 
helps :-)


More information about the cabal-devel mailing list