In the thread "strictness of unused arguments", Max Bolingbroke wrote:
There is nothing *published* (Simon has a half-written one lying around though)... Unfortunately the weird behaviour you are seeing is due to... one of the unpublished bits...
There are various critical parts of the inner workings of GHC that are poorly understood outside of the GHC team. Strictness analysis and other optimizations, and the syntax and semantics of GHC Core, immediately come to my mind. There is much more. As a user of GHC, I would vote for a full two-month delay in the next release of GHC to allow the GHC team to devote two months of their time exclusively to writing documentation. Thanks, Yitz
On 14/03/2010 07:50, Yitzchak Gale wrote:
In the thread "strictness of unused arguments", Max Bolingbroke wrote:
There is nothing *published* (Simon has a half-written one lying around though)... Unfortunately the weird behaviour you are seeing is due to... one of the unpublished bits...
There are various critical parts of the inner workings of GHC that are poorly understood outside of the GHC team. Strictness analysis and other optimizations, and the syntax and semantics of GHC Core, immediately come to my mind. There is much more.
As a user of GHC, I would vote for a full two-month delay in the next release of GHC to allow the GHC team to devote two months of their time exclusively to writing documentation.
While it would be lovely to be able to do that, in reality both Simon PJ and myself work in a research lab and it would be hard for us to take two months out to write compiler internals documentation. We try to write docs when we can, e.g. I recently wrote a bunch of stuff about the GC internals on the wiki: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC As I implement things, I try to document them in the commentary. Another good example of some internal docs that I wrote recently is the recompilation avoidance algorithm: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/RecompilationAv... So over time, the docs gradually get better. I'd like to encourage others looking at the sources to help us do this too, and to go through the existing docs to update them, make sure they're properly cross-linked, and so on. Cheers, Simon
| > As a user of GHC, I would vote for a full two-month delay in | > the next release of GHC to allow the GHC team to devote | > two months of their time exclusively to writing documentation. | | While it would be lovely to be able to do that, in reality both Simon PJ | and myself work in a research lab and it would be hard for us to take | two months out to write compiler internals documentation. We try to | write docs when we can, e.g. I recently wrote a bunch of stuff about the | GC internals on the wiki: Another way in which we try to document things is by writing papers. For example I am elbows-deep in a paper about the new dataflow analysis and rewrite engine in the back end. And another about the new type inference engine. Not every aspect of GHC has a paper about it, and the papers are not always up to date wrt the implementation, but they are at least carefully written and reviewed. As Simon says, GHC is a collaborative project. We have two kinds of collaborative documentation: * User-oriented documentation lives on the HaskellWiki, here, under "Collaborative documentation" http://haskell.org/haskellwiki/GHC * Developer-oriented documentation (developers of GHC itself, that is) lives on the GHC Trac Wiki, here, both in the main Commentary and under Collaborative documentation http://hackage.haskell.org/trac/ghc/wiki/Commentary Perhaps you feel you know something about X but not everything. Please still write about it; we'd be happy to review your draft, and it's usually better than nothing about X. Simon
participants (3)
-
Simon Marlow -
Simon Peyton-Jones -
Yitzchak Gale