September 2003 - Haskell

GHC code generation
by Graham Klyne 11 Sep '03

11 Sep '03

In an exchange of ideas with a friend, this question arose: [[ I've been looking at GHC, and it looks like it has generates machine code directly rather than via C--. I know that Simon Peyton Jones (famous in the Haskell world) is one of the authors of C--, but I can find no direct connection between this and GHC or Haskell. Have you any idea where I might find this connection? ]] In my discussion with him, I had assumed that GHC generates code via C-- and a version of the GCC compiler (why else is GCC part of the GHC installation?). Can anyone shed any light or pointers? Thanks. #g ------------ Graham Klyne GK(a)NineByNine.org

3 2

The Future of Haskell discussion at the Haskell Workshop
by nilsson＠cs.yale.edu 11 Sep '03

11 Sep '03

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(a)cs.yale.edu

13 26

Circular Instance Declarations
by Ashley Yakeley 11 Sep '03

11 Sep '03

When -fallow-undecidable-instances is switched on, is there any reason why circular instances are forbidden? For instance: module CircularInsts where { data D r = ZeroD | SuccD (r (D r)); instance (Eq (r (D r))) => Eq (D r) where { ZeroD == ZeroD = True; (SuccD a) == (SuccD b) = a == b; _ == _ = False; }; newtype C a = MkC a deriving Eq; equalDC :: D C -> D C -> Bool; equalDC = (==); } When I compile this, I get this: $ ghc -fglasgow-exts -fallow-undecidable-instances -c CircularInsts.hs CircularInsts.hs:2: Context reduction stack overflow; size = 21 Use -fcontext-stack20 to increase stack size to (e.g.) 20 `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16 `Eq (D C)' arising from use of `==' at CircularInsts.hs:16 `Eq (C (D C))' arising from use of `==' at CircularInsts.hs:16 `Eq (D C)' arising from use of `==' at CircularInsts.hs:16 Would it be reasonable for the compiler to check back through the stack and allow the circularity? It will just create an ordinary recursive function. -- Ashley Yakeley, Seattle WA

4 8

Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
by Graham Klyne 11 Sep '03

11 Sep '03

At 13:13 10/09/03 +0100, Simon Marlow wrote: >Of course, if we change the language that is implied by -fglasgow-exts >now, we risk breaking old code :-) Would folk prefer existing syntax >extensions be moved into their own flags, or left in -fglasgow-exts for >now? I'm thinking of: > > - implicit parameters > - template haskell > - FFI > - rank-N polymorphism (forall keyword) > - recursive 'do' (mdo keyword) My 2p is that extensions that might be regarded as "mainstream" would usefully be included in a single easy-to-use switch like -fglasgow-exts. I think the only part I use from the above list is rank-N polymorphism, and that is imported from useful libraries. Where do multi-parameter classes fit in? #g ------------ Graham Klyne GK(a)NineByNine.org

2 1

Request for Instances
by Brandon Michael Moore 10 Sep '03

10 Sep '03

Hi everyone. I've been looking at the restrictions on instances in the H98 standard and thinking about alternatives. I would like to have a body of data type and class/instance declarations so I can test how useful various extensions would be. Please send or direct me to code that requires -fallow-undecidabe-instances. Thanks. Brandon

1 0

Type Class Problem
by Brandon Michael Moore 10 Sep '03

10 Sep '03

Hello everyone I think I'm close to useful results on the instance restrictions. First there's an obvious extension to the Haskell98 rule. The H98 rule says the instance head must be a type constructor applied to type variables, and the context must mention only those type variables. This gives a termination proof by counting constructors. If the rule is weakened to allow an arbitrary type expression in the head and require that the context mention only strict subexpressions of the head, the same proof still applies. I'm not sure how useful this is, but we might as well allow it. Second, I have half a result in the direction of allowing the context to mention types that arise from applying type constructors used in the instance head. This requires accepting regular derivations, which means the compiler would need to track all previous goals while deriving an instance, and handle a second occurance of a goal by producing a reference to the dictionary for the first occurance (which may not be constructed yet), rather than blindly continuing the derivation. First I will explain the proof method. It's related to structural induction, but not quite the same. Suppose we have a subexpression relation on type expressions such that every type expression has only a finite number of subexpressions. If instance contexts only mention subexpressions of the head, then searching for an instance for a type can only generate #of subexpressions*#of classes distinct goals. Therefore, in finite time either the derivation will fail, or we will product a regular derivaiton. Alternately, we only try to derivive an instance the first time it arises as a goal, so each time we apply an instance rule there is one less goal in the pool of possible goals, which must eventually be exhausted. The syntactic subexpression relation obviously has these properties, but it's often useful to refer to types that show up when we apply type constructors. For example, my case and a simplification of Ashley's: data Mu f = In (f (Mu f)) instance C (f (Mu f)) => C (Mu f) On the other hand, we can't unfold all type constructors because some types are irregular, or, we encounter an infinite number of types while expanding the type constructors. Define a kind indexed family of predicates on type constructors, R_K(T), where the property is true if T::K, T is regular (including expanding the insides of lambdas), and if K=K1->K2, then R_K2(T t) for all t such that R_K1(t). Say a type is regularity preserving if it satisfies the predicate corresponding to its kind. Any type expression build entirely from regularity preserving type constructors will be regular. I think that a subexpression relation that allows expanding applications regularity preserving type constructors will give any type a finite number of subexpressions, but I don't know enough about the structure of regularity preserving type constructors to prove it. The missing half here is an algorithm for testing whether a type constructor is regularity preserving. For this the body of the type constructor can be simplified to consist of just the type constructor applications in the body. Apply the type constructor to skolem arguments, and check whether the resulting tree is regular. I don't know how to do this. Another approach is to draw out a dependency graph between type constructors, with an edge from A to B for each use of B in the definition of A, labeled with the arguments used. Then the question is whether starting from out type applied to tyvars we can find some path through the graph that generates an infinite number of types, where we keep track of the current node and the current arguments, and modify the arguments as directed by a label when moving along an edge. I don't know if the search can even a tail repeating path that witnesses the irregularity, let alone a family of paths that can be tested. Any assistance here would be appreciated. Thanks Brandon

1 0

A gentle reminder: Coordination2004 Deadline is approaching
by etuosto＠di.unipi.it 10 Sep '03

10 Sep '03

[[ -- Apologies for multiple copies of this message -- ]] COORDINATION 2004 Second Call for Papers Sixth International Conference on Coordination Models and Languages 24-27 February 2004 -- Pisa, Italy =============================================================================== IMPORTANT DATES: Submission of abstract: September 22, 2003 Submission of Papers: September 29, 2003 ** FIRM ** Notification of Acceptance: November 14, 2003 Camera-Ready Copy: December 4, 2003 TOPICS OF INTEREST (include, but are not limited to): * Theoretical models and foundations for coordination * Coordination middlewares * Specification, refinement, and analysis of software architectures * Architectural, and interface definition languages * Agent-oriented languages and models * Dynamic software architectures * Component Programming * Web Services * Coordination in Peer to Peer and Grid Computing * Tools and environments for the development of coordinated applications * Industrial relevance of coordination and software architectures * Domain-specific software coordination models and case studies. PROCEEDINGS The conference proceedings will be published by Springer, in the Lecture Notes in Computer Science series. For submissions and further information see: http://www.di.unipi.it/Coordination2004

1 0

Haskell for non-Haskell's sake
by Hal Daume III 10 Sep '03

10 Sep '03

Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities & Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple "I do" to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider "Haskell for Haskell's sake" include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) Thanks, - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

27 29

Future of Haskell records
by George Russell 10 Sep '03

10 Sep '03

I'm quite happy to have Haskell records remain the way they are. I've used ML quite a lot, which of course has records without constructors. But the problem with this is that (1) you get massive error messages; (2) there isn't a mechanism for filling in empty slots. I don't think you really gain anything except the labour of not typing the constructor name. On the other hand, you would lose the Haskell feature by which when several constructors all have a record of the same name with the same type, you can extract that record in one operation. This is occasionally really useful, see the spaceships paper in this year's Haskell workshop. I am definitely against anything which breaks code in any major way, as I'm sitting on top of 90,000 lines of Haskell, which uses records a lot. (I like records.) Perhaps the only things which could be improved would be : (1) when some constructors have a field of type X, and others do not, it would be nice to have a way of getting a Maybe X value out. (2) I wish there were some way of allowing constructors for different types to share a record name. But perhaps the overloading required would make this not worthwhile. However neither (1) nor (2) is a priority for me.

1 0

Future of Haskell: GUI development
by Axel Simon 10 Sep '03

10 Sep '03

[This is a summary on the GUI discussion at the Haskell workshop/HIM, as announced by Henrik Nilsson] The future development of GUI libraries for Haskell 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(a)haskell.org . All input (and development effort) is welcome. Axel (on behalf of the GUI Task Force).

1 0