
This message is to keep everyone updated on our future release plans. We are currently planning two new releases around the end of August: one from the STABLE branch and one from the HEAD. STABLE: 6.2.2 ------------- This will be the final release from the 6.2 branch, containing bugfixes only relative to 6.2.1. Please if you have any outstanding bugs in 6.2.1, drop us a note. We'll be doing a sweep through the SourceForge bug list and any other outstanding bugs that we're aware of before the release, but we'd be grateful if you could remind us if you still have an outstanding bug in 6.2.1 so that we can be sure not to miss anything. HEAD: 6.4 --------- This release will have some significant rewrites, and is likely to be less stable than 6.2.2. Highlights: - completely new back-end (post-STG) based on a C-- intermediate language, including a largely rewritten native code generator. - Source locations inside the compiler are now much more comprehensive: pretty much every syntactic entity has an exact source span, so error messages should be a lot more accurate. - generalised algebraic data types (currently in development, might not make it into the release). The following features are also slated for inclusion: - integration of some of the DData libraries - the new System.Process library - Data.Version library and System.Info.compilerVersion - various Template Haskell changes/fixes - changes to support Cabal - FFI updates (CString locale translation) - threaded RTS: I/O multiplexing simplification & speedup - new X11 & Win32 libraries(?) Many of these features aren't in the tree yet, and/or haven't been finished. The end-Aug release date is variable, depending on how much progress we make before then, and the feature list might change too. Feedback welcome as usual - I've probably forgotten lots of stuff on these lists. Cheers, Simon

"Simon Marlow"
- completely new back-end (post-STG) based on a C-- intermediate language, including a largely rewritten native code generator.
I'm looking forward to this.
- generalised algebraic data types (currently in development, might not make it into the release).
What does this mean exactly? Ian Lynagh has built ghc-cvs debs, is anything in particular ghc-cvs users should try to test? -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby

Feedback welcome as usual - I've probably forgotten lots of stuff on these lists.
Cheers, Simon
Hi Simon, Since you are working on the backend is there any chance that GHC could support symbol names in the heap? I tried to add this previously and failed miserably. I would be happy with a flag, such as '-debug-symbols' or somesuch, that keeps source symbol names, at least for data constructors, and possibly functions. This would be a BIG win for buddha and possibly other debugging tools. Currently I have to turn on -prof which is a bad hack. BTW Will there be any big changes to the heap representation of objects with the new backend? Cheers, Bernie.
participants (3)
-
Bernie Pope
-
Shae Matijs Erisson
-
Simon Marlow