[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.