The Future of Haskell discussion at the Haskell Workshop

[nilsson@cs.yale.edu]

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