|
# GHC Status April 2007
|
|
CONVERSION ERROR
|
|
|
|
|
|
|
|
Error: HttpError (HttpExceptionRequest Request {
|
|
GHC continues to thrive. One indicator of how widely GHC is used is the
|
|
host = "ghc.haskell.org"
|
|
number of bug reports we get. Here is the number of Trac tickets milestoned
|
|
port = 443
|
|
for the last few releases of GHC:
|
|
secure = True
|
|
|
|
requestHeaders = []
|
|
**Simon or Ian: can you add a little table here?**
|
|
path = "/trac/ghc/wiki/Status/April07"
|
|
|
|
queryString = "?version=12"
|
|
|
|
method = "GET"
|
|
You could interpret these figures as saying that GHC is getting steadily
|
|
proxy = Nothing
|
|
more unreliable! But we don't think so...we believe that it's
|
|
rawBody = False
|
|
mostly a result of more people using GHC, for more applications, on more
|
|
redirectCount = 10
|
|
platforms.
|
|
responseTimeout = ResponseTimeoutDefault
|
|
|
|
requestVersion = HTTP/1.1
|
|
|
|
}
|
|
We are getting more help from the community, too. As well as
|
|
(StatusCodeException (Response {responseStatus = Status {statusCode = 403, statusMessage = "Forbidden"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 10 Mar 2019 07:03:17 GMT"),("Server","Apache/2.2.22 (Debian)"),("Strict-Transport-Security","max-age=63072000; includeSubDomains"),("Vary","Accept-Encoding"),("Content-Encoding","gzip"),("Content-Length","255"),("Content-Type","text/html; charset=iso-8859-1")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>403 Forbidden</title>\n</head><body>\n<h1>Forbidden</h1>\n<p>You don't have permission to access /trac/ghc/wiki/Status/April07\non this server.</p>\n<hr>\n<address>Apache/2.2.22 (Debian) Server at ghc.haskell.org Port 443</address>\n</body></html>\n"))
|
|
poeple who regularly commit patches, we get a steady trickle of patches
|
|
|
|
emailed in from folk who (mostly) do not have commit rights, but who have built GHC,
|
|
Original source:
|
|
debugged a problem, sent us the patch. Our thanks go out to
|
|
|
|
Aaron Tomb, Alec Berryman, Alexey Rodriguez, Andrew Pimlott,
|
|
```trac
|
|
Andy Gill, Bas van Dijk, Bernie Pope, Bjorn Bringert,
|
|
= GHC Status April 2007 =
|
|
Brian Alliet, Brian Smith, Chris Rodrigues, Claus Reinke,
|
|
|
|
David Himmelstrup, David Waern, Judah Jacobson, Isaac Jones,
|
|
GHC continues to thrive. One indicator of how widely GHC is used is the
|
|
Lennart Augustsson, Lennart Kolmodin, Manuel M T Chakravarty,
|
|
number of bug reports we get. Here is the number of Trac tickets milestoned
|
|
Pepe Iborra, Ravi Nanavati, Samuel Bronson, Sigbjorn Finne,
|
|
for the last few releases of GHC:
|
|
Spencer Janssen, Sven Panne, Tim Chevalier, Tim Harris,
|
|
|
|
Tyson Whitehead, Wolfgang Thaller and anyone else who has contributed
|
|
'''Simon or Ian: can you add a little table here?'''
|
|
but we have accidentally omitted.
|
|
|
|
|
|
You could interpret these figures as saying that GHC is getting steadily
|
|
|
|
more unreliable! But we don't think so...we believe that it's
|
|
As a result of this heavy usage, it has taken us nearly six months to
|
|
mostly a result of more people using GHC, for more applications, on more
|
|
stabilise GHC 6.6.1, fixing over 100 reported bugs or infelicities in
|
|
platforms.
|
|
the already-fairly-solid GHC 6.6. GHC 6.6.1 should be released by the
|
|
|
|
time you are reading this.
|
|
We are getting more help from the community, too. As well as
|
|
|
|
poeple who regularly commit patches, we get a steady trickle of patches
|
|
|
|
emailed in from folk who (mostly) do not have commit rights, but who have built GHC,
|
|
As a result, the HEAD (which will become GHC 6.8) embodies nine months
|
|
debugged a problem, sent us the patch. Our thanks go out to
|
|
of development work since we forked the tree for GHC 6.6. We are now
|
|
Aaron Tomb, Alec Berryman, Alexey Rodriguez, Andrew Pimlott,
|
|
aiming to get a stable set of features implemented in the HEAD, with
|
|
Andy Gill, Bas van Dijk, Bernie Pope, Bjorn Bringert,
|
|
a view to forking off the GHC 6.8 branch in the early summer. As
|
|
Brian Alliet, Brian Smith, Chris Rodrigues, Claus Reinke,
|
|
our last HCAR report indicated, there will be lots of new stuff in
|
|
David Himmelstrup, David Waern, Judah Jacobson, Isaac Jones,
|
|
GHC 6.8. The rest of this entry describes the features that
|
|
Lennart Augustsson, Lennart Kolmodin, Manuel M T Chakravarty,
|
|
are likely to end up in 6.8.
|
|
Pepe Iborra, Ravi Nanavati, Samuel Bronson, Sigbjorn Finne,
|
|
|
|
Spencer Janssen, Sven Panne, Tim Chevalier, Tim Harris,
|
|
|
|
Tyson Whitehead, Wolfgang Thaller and anyone else who has contributed
|
|
You can find binary snapshots at
|
|
but we have accidentally omitted.
|
|
the download page [http://www.haskell.org/ghc/dist/current/dist/](http://www.haskell.org/ghc/dist/current/dist/)
|
|
|
|
or build from sources available via the darcs
|
|
As a result of this heavy usage, it has taken us nearly six months to
|
|
repository ([ http://darcs.haskell.org/ghc/](http://darcs.haskell.org/ghc/)).
|
|
stabilise GHC 6.6.1, fixing over 100 reported bugs or infelicities in
|
|
|
|
the already-fairly-solid GHC 6.6.
|
|
|
|
|
|
Simon Peyton Jones, Simon Marlow, Ian Lynagh
|
|
As a result, the HEAD (which will become GHC 6.8) embodies nine months
|
|
|
|
of development work since we forked the tree for GHC 6.6. We are now
|
|
## Type system and front end
|
|
aiming to get a stable set of features implemented in the HEAD, with
|
|
|
|
a view to forking off the GHC 6.8 branch in the early summer. As
|
|
- We have completely replaced GHC's intermediate language with
|
|
our last HCAR report indicated, there will be lots of new stuff in
|
|
System FC(X), an extension of System F with explicit equality
|
|
GHC 6.8. The rest of this entry describes the features that
|
|
witnesses. This enables GHC to support GADTs and associated types,
|
|
are likely to end up in 6.8.
|
|
with two new simple but powerful mechanisms. The paper is at
|
|
|
|
[ http://research.microsoft.com/\~simonpj/papers/ext-f/](http://research.microsoft.com/~simonpj/papers/ext-f/).
|
|
You can find binary snapshots at
|
|
Much of the conversion work was done by Kevin Donnelly, while he
|
|
the download page http://www.haskell.org/ghc/dist/current/dist/
|
|
was on an internship at Microsoft.
|
|
or build from sources available via the darcs
|
|
|
|
repository (http://darcs.haskell.org/ghc/).
|
|
- Manuel Chakravarty has implemented *type-indexed data types*,
|
|
|
|
a modest generalisation of the *associated data types*
|
|
Simon Peyton Jones, Simon Marlow, Ian Lynagh
|
|
of our POPL'05 paper
|
|
|
|
[ http://research.microsoft.com/\~simonpj/papers/assoc-types/](http://research.microsoft.com/~simonpj/papers/assoc-types/).
|
|
|
|
|
|
== Type system and front end ==
|
|
This part is done. Now we are working on indexed *type synonyms*
|
|
|
|
(aka type functions), which are considerably trickier that
|
|
* We have completely replaced GHC's intermediate language with
|
|
indexed data types, at least so far as type inference is concerned.
|
|
System FC(X), an extension of System F with explicit equality
|
|
Tom Schrijvers is in Cambridge for three months to help us use ides
|
|
witnesses. This enables GHC to support GADTs and associated types,
|
|
from Constraint Handling Rules to solve the inference problem.
|
|
with two new simple but powerful mechanisms. The paper is at
|
|
Indexed type synonyms will almost completely fill the spot occupied
|
|
http://research.microsoft.com/~simonpj/papers/ext-f/.
|
|
by the always-troublesome functional dependencies, so we are quite
|
|
Much of the conversion work was done by Kevin Donnelly, while he
|
|
excited about this.
|
|
was on an internship at Microsoft.
|
|
|
|
|
|
Details are at [ http://haskell.org/haskellwiki/GHC/Indexed_types](http://haskell.org/haskellwiki/GHC/Indexed_types).
|
|
* Manuel Chakravarty has implemented ''type-indexed data types'',
|
|
|
|
a modest generalisation of the ''associated data types''
|
|
- Simon PJ finally implemented *implication constraints*, which are
|
|
of our POPL'05 paper
|
|
the key to fixing the interaction between
|
|
http://research.microsoft.com/~simonpj/papers/assoc-types/.
|
|
GADTs and type classes. GHC's users have been very polite about
|
|
[[BR]][[BR]]
|
|
this collection of bugs, but they are now finally fixed.
|
|
This part is done. Now we are working on indexed ''type synonyms''
|
|
Implication constraints are described by Martin Sulzmann:
|
|
(aka type functions), which are considerably trickier that
|
|
[ http://www.comp.nus.edu.sg/\~sulzmann/publications/tr-eadt.ps.gz](http://www.comp.nus.edu.sg/~sulzmann/publications/tr-eadt.ps.gz).
|
|
indexed data types, at least so far as type inference is concerned.
|
|
|
|
Tom Schrijvers is in Cambridge for three months to help us use ides
|
|
- Björn Bringert (a GHC Hackathon graduate) implemented
|
|
from Constraint Handling Rules to solve the inference problem.
|
|
*standalone deriving*, which allows you to write a `deriving`
|
|
Indexed type synonyms will almost completely fill the spot occupied
|
|
declaration anywhere, rather than only where the data type is
|
|
by the always-troublesome functional dependencies, so we are quite
|
|
declared. Details of the syntax have not yet quite settled. See
|
|
excited about this.
|
|
also [ http://www.haskell.org/pipermail/haskell-prime/2006-October/001725.html](http://www.haskell.org/pipermail/haskell-prime/2006-October/001725.html).
|
|
[[BR]][[BR]]
|
|
|
|
Details are at http://haskell.org/haskellwiki/GHC/Indexed_types.
|
|
- Lennart Augustsson implemented overloaded string literals. So now
|
|
|
|
just as a numeric literal has type `∀ a. Num a ⇒ a`,
|
|
* Simon PJ finally implemented ''implication constraints'', which are
|
|
so a string literal has type `∀ a. IsString a ⇒ a`,
|
|
the key to fixing the interaction between
|
|
The documentation is here: [http://www.haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions.html\#overloaded-strings](http://www.haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions.html#overloaded-strings).
|
|
GADTs and type classes. GHC's users have been very polite about
|
|
|
|
this collection of bugs, but they are now finally fixed.
|
|
|
|
Implication constraints are described by Martin Sulzmann:
|
|
A less successful feature of the last year has been the
|
|
http://www.comp.nus.edu.sg/~sulzmann/publications/tr-eadt.ps.gz.
|
|
story on impredicative instantiation (see the paper "Boxy types").
|
|
|
|
The feature is implemented, but the implementation is significantly
|
|
* Björn Bringert (a GHC Hackathon graduate) implemented
|
|
more complicated than we expected; and it delivers less benefits than
|
|
''standalone deriving'', which allows you to write a `deriving`
|
|
we hoped. For example, the system described in the paper does not
|
|
declaration anywhere, rather than only where the data type is
|
|
type-check (`runST $ foo`) and everyone complains. So Simon added
|
|
declared. Details of the syntax have not yet quite settled. See
|
|
an even more ad-hoc extension that does left-to-right instantiation.
|
|
also http://www.haskell.org/pipermail/haskell-prime/2006-October/001725.html.
|
|
|
|
|
|
|
|
* Lennart Augustsson implemented overloaded string literals. So now
|
|
The power-to-weight ratio is not good. We're still hoping that
|
|
just as a numeric literal has type `∀ a. Num a ⇒ a`,
|
|
Dimitrios Vytiniotis and Stephanie Weirich will come out with a simpler
|
|
so a string literal has type `∀ a. IsString a ⇒ a`,
|
|
system, even if it's a bit less powerful. So don't get too used to
|
|
The documentation is here: http://www.haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions.html#overloaded-strings.
|
|
impredicative instantiation as it now stands; it might change!
|
|
|
|
|
|
A less successful feature of the last year has been the
|
|
## Optimisations
|
|
story on impredicative instantiation (see the paper "Boxy types").
|
|
|
|
The feature is implemented, but the implementation is significantly
|
|
- Simon rewrote the Simplifier (again). It isn't clear whether it was that alone, or
|
|
more complicated than we expected; and it delivers less benefits than
|
|
whether something else happened too, but performance has improved quite significantly;
|
|
we hoped. For example, the system described in the paper does not
|
|
on the order of 15%. **Simon is that right?**
|
|
type-check (`runST $ foo`) and everyone complains. So Simon added
|
|
|
|
an even more ad-hoc extension that does left-to-right instantiation.
|
|
- Roman Leshchinskiy, Don Stewart, and Duncan Coutts did some beautiful
|
|
|
|
work on *fusion*; see their paper [ http://www.cse.unsw.edu.au/\~dons/papers/CSL06.html](http://www.cse.unsw.edu.au/~dons/papers/CSL06.html).
|
|
The power-to-weight ratio is not good. We're still hoping that
|
|
This fusion work is already being heavily used in the parallel array library
|
|
Dimitrios Vytiniotis and Stephanie Weirich will come out with a simpler
|
|
(see below), and they are also working on replacing foldr/build fusion with
|
|
system, even if it's a bit less powerful. So don't get too used to
|
|
stream fusion in the main base library (see their new paper
|
|
impredicative instantiation as it now stands; it might change!
|
|
[ http://www.cse.unsw.edu.au/\~dons/papers/CLS07.html](http://www.cse.unsw.edu.au/~dons/papers/CLS07.html)).
|
|
|
|
|
|
== Optimisations ==
|
|
Their work highlighted the importance of the [SpecConstr](spec-constr) transformation, which Simon
|
|
|
|
implemented several years ago. Of course, they suggested many enhancements, many of
|
|
* Simon rewrote the Simplifier (again). It isn't clear whether it was that alone, or
|
|
which Simon duly implemented; see the new paper "Constructor specialisation for Haskell
|
|
whether something else happened too, but performance has improved quite significantly;
|
|
programs" [ http://research.microsoft.com/\~simonpj/papers/spec-constr/](http://research.microsoft.com/~simonpj/papers/spec-constr/).
|
|
on the order of 15%. '''Simon is that right?'''
|
|
|
|
|
|
- Alexey Rodriguez visited us for three months from Utrecht, and implemented
|
|
* Roman Leshchinskiy, Don Stewart, and Duncan Coutts did some beautiful
|
|
a new back-end optimisation called *dynamic pointer tagging*. We have wanted
|
|
work on ''fusion''; see their paper http://www.cse.unsw.edu.au/~dons/papers/CSL06.html.
|
|
to do this for ages, but it needed a skilled and insightful hacker to make it all
|
|
This fusion work is already being heavily used in the parallel array library
|
|
happen, and Alexey is just that. This optimisation alone buys us another 15%
|
|
(see below), and they are also working on replacing foldr/build fusion with
|
|
performance for compiled programs: see the paper "Dynamic pointer tagging".
|
|
stream fusion in the main base library (see their new paper
|
|
|
|
http://www.cse.unsw.edu.au/~dons/papers/CLS07.html).
|
|
## Concurrency
|
|
[[BR]][[BR]]
|
|
|
|
Their work highlighted the importance of the SpecConstr transformation, which Simon
|
|
- Gabriele Keller, Manuel Chakravarty, and Roman Leshchinskiy, at the
|
|
implemented several years ago. Of course, they suggested many enhancements, many of
|
|
University of New South Wales, are collaborating with us on support
|
|
which Simon duly implemented; see the new paper "Constructor specialisation for Haskell
|
|
for *nested data-parallel computation* in GHC.
|
|
programs" http://research.microsoft.com/~simonpj/papers/spec-constr/.
|
|
We presented a paper at the Declarative Aspects of Multicore Programing
|
|
|
|
workshop in January 2007: [ http://www.cse.unsw.edu.au/\~chak/papers/CLPKM07.html](http://www.cse.unsw.edu.au/~chak/papers/CLPKM07.html),
|
|
* Alexey Rodriguez visited us for three months from Utrecht, and implemented
|
|
and made a first release of the
|
|
a new back-end optimisation called ''dynamic pointer tagging''. We have wanted
|
|
library in March [ http://www.cse.unsw.edu.au/\~dons/polymer.html](http://www.cse.unsw.edu.au/~dons/polymer.html).
|
|
to do this for ages, but it needed a skilled and insightful hacker to make it all
|
|
It's a pretty ambitious project, and we have quite a way to go.
|
|
happen, and Alexey is just that. This optimisation alone buys us another 15%
|
|
You can peek at the current status on the project home page:
|
|
performance for compiled programs: see the paper "Dynamic pointer tagging".
|
|
[ http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell](http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell).
|
|
|
|
|
|
== Concurrency ==
|
|
- Tim Harris added support for *invariants* to GHC's Software
|
|
|
|
Transactional Memory (STM) implementation. Paper here:
|
|
* Gabriele Keller, Manuel Chakravarty, and Roman Leshchinskiy, at the
|
|
[ http://research.microsoft.com/\~simonpj/papers/stm/](http://research.microsoft.com/~simonpj/papers/stm/).
|
|
University of New South Wales, are collaborating with us on support
|
|
|
|
for ''nested data-parallel computation'' in GHC.
|
|
- At the moment GHC's *garbage collector* is single-threaded,
|
|
We presented a paper at the Declarative Aspects of Multicore Programing
|
|
even when GHC is running on a multiprocessor. Roshan James spent
|
|
workshop in January 2007: http://www.cse.unsw.edu.au/~chak/papers/CLPKM07.html,
|
|
the summer at Microsoft on an internship, implementing a multi-threaded
|
|
and made a first release of the
|
|
GC ([ http://hackage.haskell.org/trac/ghc/wiki/MotivationForParallelization](http://hackage.haskell.org/trac/ghc/wiki/MotivationForParallelization)).
|
|
library in March http://www.cse.unsw.edu.au/~dons/polymer.html.
|
|
It works! But alas, doing GC with two processors runs no faster than
|
|
It's a pretty ambitious project, and we have quite a way to go.
|
|
with one!
|
|
You can peek at the current status on the project home page:
|
|
|
|
http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell.
|
|
|
|
|
|
Peng Li, from the University of Pennsylvania, spent an exciting
|
|
* Tim Harris added support for ''invariants'' to GHC's Software
|
|
three months at Cambridge, working on a whole new architecture for
|
|
Transactional Memory (STM) implementation. Paper here:
|
|
concurrency in GHC. (If you don't know Peng you should read his
|
|
http://research.microsoft.com/~simonpj/papers/stm/.
|
|
wonderful paper [ http://www.seas.upenn.edu/\~lipeng/homepage/papers/lz07pldi.pdf](http://www.seas.upenn.edu/~lipeng/homepage/papers/lz07pldi.pdf)
|
|
|
|
on implementing a network protocol stack in
|
|
* At the moment GHC's ''garbage collector'' is single-threaded,
|
|
Haskell.) At the moment GHC's has threads, scheduling, `forkIO`,
|
|
even when GHC is running on a multiprocessor. Roshan James spent
|
|
`MVars`, transactional memory, and more besides, all "baked
|
|
the summer at Microsoft on an internship, implementing a multi-threaded
|
|
into" the run-time system and implemented in C. If you want to
|
|
GC (http://hackage.haskell.org/trac/ghc/wiki/MotivationForParallelization).
|
|
change this implementation you have to either be Simon Marlow, or else
|
|
It works! But alas, doing GC with two processors runs no faster than
|
|
very brave indeed. With Peng (and help from Andrew Tolmach, Olin
|
|
with one!
|
|
Shivers, Norman Ramsey) we designed a new, much lower-level set of
|
|
|
|
primitives, that should allow us to implement all of the above
|
|
Peng Li, from the University of Pennsylvania, spent an exciting
|
|
*in Haskell*. If you want a different scheduler, just code it up
|
|
three months at Cambridge, working on a whole new architecture for
|
|
in Haskell, and plug it in.
|
|
concurrency in GHC. (If you don't know Peng you should read his
|
|
|
|
wonderful paper http://www.seas.upenn.edu/~lipeng/homepage/papers/lz07pldi.pdf
|
|
|
|
on implementing a network protocol stack in
|
|
Peng has a prototype running, but it has to jump the "Marlow barrier"
|
|
Haskell.) At the moment GHC's has threads, scheduling, `forkIO`,
|
|
of being virtually as fast as the existing C runtime; so far we have
|
|
`MVars`, transactional memory, and more besides, all "baked
|
|
not committed to including this in GHC, and it certainly won't be in
|
|
into" the run-time system and implemented in C. If you want to
|
|
GHC 6.8. No paper yet, but look out for a Haskell Workshop 2007 submission.
|
|
change this implementation you have to either be Simon Marlow, or else
|
|
|
|
very brave indeed. With Peng (and help from Andrew Tolmach, Olin
|
|
## Programming environment
|
|
Shivers, Norman Ramsey) we designed a new, much lower-level set of
|
|
|
|
primitives, that should allow us to implement all of the above
|
|
|
|
''in Haskell''. If you want a different scheduler, just code it up
|
|
There have been some big developments in the programming
|
|
in Haskell, and plug it in.
|
|
environment:
|
|
|
|
|
|
Peng has a prototype running, but it has to jump the "Marlow barrier"
|
|
- Andy Gill implemented the Haskell Program Coverage
|
|
of being virtually as fast as the existing C runtime; so far we have
|
|
([ http://haskell.org/haskellwiki/GHC/HPC](http://haskell.org/haskellwiki/GHC/HPC))
|
|
not committed to including this in GHC, and it certainly won't be in
|
|
option (`-fhpc`) for GHC, which is solid enough to be used to
|
|
GHC 6.8. No paper yet, but look out for a Haskell Workshop 2007 submission.
|
|
test coverage in GHC itself. (It turns out that the GHC testsuite
|
|
|
|
gives remarkably good coverage over GHC already.)
|
|
== Programming environment ==
|
|
|
|
|
|
- Pepe Iborra, Bernie Pope, and Simon Marlow have leveraged the same
|
|
There have been some big developments in the programming
|
|
"tick" points used in the Haskell Program Coverage work to implement
|
|
environment:
|
|
a breakpoint debugger in GHCi. Unlike HAT, which transforms the whole
|
|
|
|
program into a new program that generates its own (massive) trace,
|
|
* Andy Gill implemented the Haskell Program Coverage
|
|
this is a cheap-and-cheerful debugger. It simply lets you set
|
|
(http://haskell.org/haskellwiki/GHC/HPC)
|
|
breakpoints and look around to see what is in the heap, more in the
|
|
option (`-fhpc`) for GHC, which is solid enough to be used to
|
|
manner of a conventional debugger. No need to recompile your program: it
|
|
test coverage in GHC itself. (It turns out that the GHC testsuite
|
|
"just works".
|
|
gives remarkably good coverage over GHC already.)
|
|
|
|
|
|
- Aaron Tomb and Tim Chevalier are working on resurrecting External
|
|
* Pepe Iborra, Bernie Pope, and Simon Marlow have leveraged the same
|
|
Core **\\url{...}**, whose implementation was not only bit-rotted, but also poorly
|
|
"tick" points used in the Haskell Program Coverage work to implement
|
|
designed (by Simon). By GHC 6.8 we hope to be able to spit out External
|
|
a breakpoint debugger in GHCi. Unlike HAT, which transforms the whole
|
|
Core for any program, perhaps transform it in some external program,
|
|
program into a new program that generates its own (massive) trace,
|
|
and read it in again, surviving the round trip unscathed.
|
|
this is a cheap-and-cheerful debugger. It simply lets you set
|
|
|
|
breakpoints and look around to see what is in the heap, more in the
|
|
- **Simon M please amplify**
|
|
manner of a conventional debugger. No need to recompile your program: it
|
|
GHC API changes, compile to object code inside GHCi
|
|
"just works".
|
|
|
|
|
|
- **Simon, can you write something about GHC-Haddock, even if
|
|
* Aaron Tomb and Tim Chevalier are working on resurrecting External
|
|
it's just a pointer to the Haddock entry?**
|
|
Core '''\url{...}''', whose implementation was not only bit-rotted, but also poorly
|
|
|
|
designed (by Simon). By GHC 6.8 we hope to be able to spit out External
|
|
## Libraries
|
|
Core for any program, perhaps transform it in some external program,
|
|
|
|
and read it in again, surviving the round trip unscathed.
|
|
- The set of "corelibs" has been further streamlined, with `parsec`, `regex-base`,
|
|
|
|
`regex-compat`, `regex-posix` and `stm` moved to extralibs in the HEAD. This disentangles
|
|
* '''Simon M please amplify'''
|
|
releases of these packages from the GHC release process, and also means that development
|
|
GHC API changes, compile to object code inside GHCi
|
|
builds of GHC are quicker as they don't need to build those libraries.
|
|
|
|
|
|
* '''Simon, can you write something about GHC-Haddock, even if
|
|
**Simon M or Ian pls elaborate**
|
|
it's just a pointer to the Haddock entry?'''
|
|
|
|
|
|
- base package breakup (see discussion on libraries list) |
|
== Libraries ==
|
|
|
|
|
|
|
|
* The set of "corelibs" has been further streamlined, with `parsec`, `regex-base`,
|
|
|
|
`regex-compat`, `regex-posix` and `stm` moved to extralibs in the HEAD. This disentangles
|
|
|
|
releases of these packages from the GHC release process, and also means that development
|
|
|
|
builds of GHC are quicker as they don't need to build those libraries.
|
|
|
|
|
|
|
|
'''Simon M or Ian pls elaborate'''
|
|
|
|
|
|
|
|
* base package breakup (see discussion on libraries list)
|
|
|
|
|
|
|
|
``` |