Dear Haskellers, This year's Haskell Workshop, held in Uppsala as a part of PLI, traditionally concluded with a discussion on the future of Haskell. This time an attempt was made to structure the discussion a little bit by focusing on two specific topics, and by having each topic being introduced by a short presentation. The first topic was Haskell records, introduced by Simon Peyton Jones, Microsoft Research, Cambridge, UK. The second topic was GUI libraries for Haskell, introduced by Axel Simon, the University of Kent, UK. While the current Haskell record system, or rather support for labeled fields, is vastly superior to not having any record facility at all, and appealing due to its simplicity and not incurring any run-time penalty, most people would agree that it does leave a lot be desired. However, they would not necessarily agree on exactly what is to be desired: the design space is quite large, and it is not easy to evaluate how useful various record features would be in practice, and if the cost in terms of increased language complexity and backwards compatibility issues is warranted. Unsurprisingly, opinions expressed during the discussion were rather divided. In the end, it seemed that the fact that the present system, despite its faults, is simple and has proved to be useful convinced a majority of the people present that if the system were to be improved, it should only be rather modest improvements that would not break backward compatibility. For example, one of the most annoying limitations of the present system is that record labels have to be distinct. Maybe this restriction could be lifted without sacrificing compatibility. Here is how Simon Peyton Jones summarized the discussion: The conclusion I took away was this There are undoubted advantages to having better records, but (a) they all make the language more complicated (b) there are many possible design choices (not only has/lacks, but also record concatenation, length vs depth subtyping, and more I'm sure) (c) they almost certainly conflict with existing programs (d) the existing system is really not too bad That all argues for the status quo. I did have a conversation with Peter Thiemann afterwards. We discussed a record system which is an upward compatible extension of what we have now, though less powerful than the variants I have previously proposed. * Records are not anonymous. e.g. {x::Int, y::Bool} is not a type They are declared exactly as now, so that data T = T { x::Int, y::Bool } declares a type T. * However, you can have more than one record with the same field name. So the field selectors are overloaded, much as with has-predicates x :: (t has x::a) => t -> a * So a function like f v = v.x + v.y would get the inferred type f :: (t has x::a, t has y::a, Num a) => t -> a * Also retain Haskell's existing record construction and update syntax could be possible. The GUI library discussion focused on questions such as what exactly are the desirable properties of such a library. For example, to what extent is it necessary that applications are able to adopt the look-and-feel of the platform on which they happen to be running. Related to this was the question of whether to focus efforts on a Common GUI API (CGA) that would allow applications to adapt to specific platforms, or whether it would be sufficient to go for something based on an existing cross-platform API, such as wxWindows, even if that meant violating certain look-and-feel aspects on certain platforms, and inability to access platform-specific functionality. Axel Simon has promised to e-mail a more complete record of the GUI-part of the discussion shortly. All the best, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu