HIM 2003: Slides and Notes

Modular cloning

Karl-Filip Faxén, KTH, Stockholm, Sweden

Push/enter vs. eval/apply

Simon Peyton-Jones, Microsoft Research, Cambridge, UK
Jointly with Simon Marlow

The implementation of overloading in Chameleon

Martin Sulzmann, National University of Singapore

We discuss how to implement overloading in Chameleon. Chameleon is a Haskell-style language where dependencies among overloaded identifers are expressed in terms of Constraint Handling Rules (CHRs). Our implementation scheme for Chameleon is based on the well-known evidence translation scheme. The novelty of our approach is that evidence can be constructed out of CHR derivations. We describe in detail the evidence translation of Chameleon to the Hindley/Milner fragment of Haskell. Our translation scheme even applies to Haskell style type classes.

Slides (PS)

Type analysis with type classes

Manuel Chakravarty, University of New South Wales, Sydney
Jointly with Gabriele Keller

Slides (PS)

The Utrecht Haskell Compiler (UHC) and related tools

Doaitse Swierstra, Universiteit Utrecht, Utrecht, The Netherlands
Jointly with Atze Dijkstra

This talk gives an overview of UHC (the Utrecht Haskell Compiler) that is in the works, and tell something about the tools we use and the syntax-macro mechanism that comes with the tools “for free”.

Slides (PDF) Sample macro file

Demo: wxHaskell: a portable and native GUI library for Haskell

Daan Leijen, Universiteit Utrecht, Utrecht, The Netherlands

wxHaskell is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore build on top of wxWindows -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge).

Discussion: Haskell GUIs

Introduced and chaired by Axel Simon, University of Kent, UK

Discussion summary by Axel Simon:

The development of Haskell applications with a graphical user interface has long been complicated by the large number of mostly incomplete libraries. In spring of this year people tried to focus the development effort and came up with the idea of a Common GUI API (CGA for short) which should define an intersection of three major platform APIs (Win32, Gnome/Gtk and Mac OS X) and that addresses the requirements of the platform's style guide (or human interface guidelines). The process of defining this CGA is a major undertaking. The alternative is to use a readily available cross-platform API, like wxWindows, at the expense of creating applications that might violate a platform's style guide and the cannot make use of platform specific functionality. A quick poll at the Haskell workshop revealed that 1/3 of the people thought that the CGA approach is worthwhile, 2/3 thought that the cross-platform approach is adequate. Hence the CGA idea as it stands right now will not be pursued.

The discussions at the Haskell Implementor Meeting (HIM) yielded some interesting options (or compromises) that could help to target and unify the development effort of the different library maintainers. In particular we would like to

focus development on wxWindows (in form of wxHaskell) as this cross-platform toolkit should be adequate for most needs;
move the programming model of Yahu (Attribute/set/get functionality) into the Haskell library hierarchy so that other (GUI) libraries can use it;
exploit wxWindow's capability to extract platforms specific handles/objects. The goal is to use other libraries (like gtk+hs, gtk2hs, Mocca, etc.) if wxWindows does not provide the needed functionality.
mention the names of the maintainers of each GUI library on the Haskell web site so that programmers can estimate how well-maintained a library is. Update these names regularly.

In case people feel inclined to still pursue the CGA idea, one of the following two routes could be taken:

re-expose parts of wxHaskell in a way that forces the user to write applications that look and feel native on different platforms, i.e. a “Common GUI API on top of wxWindows.”
write a GUI Builder application for Haskell; it would surely make Haskell itself more attractive as a rapid development language (such a Builder could also cater for the look-and-feel requirements of the different platforms).

Please send any comments or critics to gui@haskell.org. All input (and development effort) is welcome.

Axel (on behalf of the GUI Task Force)