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