[I originally sent this message to glasgow-haskell-users and
glasgow-haskell-bugs, but it occurred to me that it might be of more general
interest, so I'm sending it to the Haskell mailing list too.]
Dear GHC users and co-implementors
We are about to return from sabbatical in Oregon back to Glasgow, so
now seems a good time to let you know the current state of GHC affairs, and
something about our future plans.
Simon and Sigbjorn
Who's doing what
~~~~~~~~~~~~~~~~
Things have been a bit slow this year, because I have been between grants,
so there have been no research assistants working on GHC. Sigbjorn has
heroically done wonders, but he's really working on his thesis, so I only
let him out to play with GHC one day a week these days.
Because I've been on sabbatical I have personally had more time to spend on
GHC, but I usually cause untold chaos when let loose to play, so you may not
have noticed a great improvement. GHC *is* much more beautiful inside, I
promise. It's some 10k lines shorter than GHC 0.29 in spite of growing to
accommodate Haskell 1.4.
and Simon Marlow (of Erlang type-system fame -- ICFP'97) will join up. And
there'll be several research students joining the fun.
And there's you! Several of you have been extraordinarily helpful this
year, identifying bugs, suggesting fixes, and putting up builds that we
didn't get around to producing. Thank you Alex, Marc, Sven, Einar, Stefan,
Meurig, Jon, Ralf, Tomasz, Andre... GHC is much better because of your help.
I read a nice paper recently "The cathedral and the bazaar" by Eric Raymond,
reflecting on his experience Linux, and in particular of developing
"fetchmail". You can find it at
http://locke.ccil.org/~esr/writings/cathedral.html
It's really worth reading. One particular thing he suggests is making very
frequent releases, even if they are buggy (like daily when in intense
development mode). I've been brought up to think that releasing buggy
software is likely to discourage one's users, but perhaps not if the
non-buggy versions (ha!) are prominently so flagged, so that "users" can
stick to them, while "developers" can pull in the latest one. Comments?
(Read the Raymond paper first.)
Incidentally, we have always intended that others can use GHC as a substrate
into which to "plug" new passes. I'm painfully aware that it's a daunting
monster. However, things have got a bit better this year. The "make" system
is vastly improved, and HAS A MANUAL that describes how it all works and how
to use it. The internals of the compiler are simpler and cleaner. So have
a go!
We are also always very interested in programs to add to our nofib test
suite, especially if they stress or break the current comiler. Send your
programs! If they're in our suite then we'll discover when the next release
doesn't run them, rather than you having to...
So much for who's doing what. Now for....
What's cooking
~~~~~~~~~~~~~~
* We're actively working with Erik Meijer, Daan Leijen, Alastair Reid, Colin
Runciman and Malcolm Wallace to continue the Green-Card idea. The
currently-released Green Card allows Haskell to call C, and there are now
back ends for GHC, Hugs and nhc. We have a not-yet-released tool that
allows Haskell to call COM (Microsoft's Common Object Model). We are
designing ways of letting C, and then COM, call Haskell. All this is
crucial to making Haskell something that Real People can use for Real
Projects.
* During this year we've been working on a successor to GHC's Core
intermediate language. There are two papers that describe this work:
Henk: a typed intermediate language
Bridging the gulf: a common intermediate langauge for ML and Haskell
Both are attached to my OGI web page http://www.cse.ogi.edu/~simonpj. If
you are using Core, don't worry. Actually implementing a new IL will be a
heart-liver-and-lung transplant operation, and I don't expect to undertake
it for at least a year. But the design is interesting!
* I have grown increasingly dissatisified with using C as a portable
assembler, so have been working with others at OGI (Dino Oliva, Thomas
Nordin, Andrew Tolmach) and elsewhere to develop a purpose-designed portable
assembly language, called C--. We're still refining the design, but I think
we'll put out a public straw man for you to shoot at fairly soon; meanwhile
if the idea grabs you, get in touch and I'll send you a copy.
* As you know, we plan to integrate GHC and Hugs, so that Hugs can run
GHC-compiled binaries. That involves giving GHC and Hugs a common run-time
system, so that Hugs byte-codes manipulate exactly the same run-time
structures as GHC-compiled code expects. This work is collaborative with
Yale (esp Alastair Reid) and Nottingham (Mark Jones), and has been moving
rather slowly. We have a draft RTS design document, and I hope things will
move faster when we get back to Glasgow. This is a high-priority task.
* As you also probably know, there's a Standard Haskell design exercise under
way (check out http://www.cs.chalmers.se/~rjmh/Haskell/)
One question "on the table" is whether Standard Haskell should include
multi-parameter type classes. I'm now convinced that it should, so I've got
to implement them, and preferably sooner rather than later.
* Other type system extensions:
- polytypes in constructor arguments, and indeed for any function
that has a type signatures, are implemented
- existential types are not yet implemented, but will be (but after
multi-parameter type classes
* Pattern guards were a little design exercise I went through this year. GHC
2.04 includes them.
* GHC 2.05 will self-boot properly. This has meant sorting out the story
about how GHC compiles mutually recursive modules with the Haskell 1.4
module system.
* The specialiser (which specialises overloaded functions) still isn't back
in there. I keep postponing it because it's a hairy corner. Volunteers??
Coda
~~~~
So there's a lot on the go... the souce language, the intermediate language,
the target language, the run-time system, the foreign language interface;
just about everything in fact. It keeps life interesting. Please keep
telling us what you like and don't like about GHC, and make suggestions for
how it could be improved. Even better, improve it, or build associated
tools. We'll gladly give access to our network-accessible CVS code
repository to serious contributors.
We'll will be off the air for 2-3 weeks now while we transfer back
to the UK. Back in action mid August.
